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PREFACE 


The  need  for  a  centralized  database  and  data  management  system  has 
long  been  recognized  by  AFIT  as  essential  for  efficient  operation  in  the 
face  of  an  ever  increasing  student  enrollment  and  the  associated  adminis-* 
trative  load.  Until  the  completion  of  this  thesis,  AFIT  had  been  unable 
to  complete  the  groundwork  for  a  solution  to  their  information  management 
needs  because  of  other  problems  associated  with  completely  modernizing 
the  AFIT  data  automation  program. 

To  bring  a  project  of  this  magnitude  to  completion  and  at  the  same 
time  produce  results  which  are  accurate,  useful  and  meaningful  to  AFIT 
required  the  combined  efforts  of  many  people.  Grateful  appreciation  is 
extended  to  the  AFIT  Computer  Configuration  Board  (CCB)  and  the  heads  of 
all  the  AFIT  directorates  and  divisions  who  willingly  and  supportively 
participated  in  the  data  analysis  interviews  and  to  Ms.  Jean  Darjean  from 
AFIT/ACD. 

Heartfelt  thanks  is  given  to  our  thesis  advisor  Ma j .  Chuck  Lillie 
and  to  committee  member  Dr.  Henry  Potoczny  who  provided  tremendous  moral 
support,  Innumerable  impartial  evaluations  and  recommendations  and 
managed  to  keep  us  on  track. 

Special  gratitude  is  extended  to  three  people  who,  without  their 
help,  this  project  probably  could  not  have  been  completed  on  time.  Capt. 
Brian  Van  Ormann,  AFIT/CI,  spent  many  hours  helping  us  understand  the 
Civilian  Institution  Programs  Directorate's  requirements  and  problems. 
Capt.  Ricardo  Cuadros  and  Lt.  Tim  Mayberry,  two  fellow  graduate  students, 
lent  their  knowledge  and  manpower  to  the  completion  of  the  applications 


programs  design  (chapter  IV). 

Capt.  Ricks  would  like  to  express  his  deepest  appreciation  to  those 
fellow  officers  and  civilians  of  the  Air  Force  Data  Services  Center  who 
provided  him  with  the  background  and  courage  to  undertake  this  type  of 
project.  I  would  especially  like  to  thank  LtCol.  Marvin  Lerfald  who  took 
a  chance  on  a  brand  new  2Lt.  and  helped  him  mature  both  as  an  officer  and 
as  a  professional  data  automator.  I  would  also  like  to  recognize  Maj. 
Craig  Coeller  and  the  other  members  of  the  AFDSC/GKP  PDS  team  for  their 
friendship  and  professionalism  as  well  as  the  knowledge  we  shared  during 
the  implementation  of  the  FAS  database  and  applications  programs. 

Lastly  and  certainly  not  least  1  would  like  to  thank  Lt.  Colburn  for 
his  time  and  patience.  These  were  difficult  times  and  his  cool  head  and 
academic  demeanor  kept  me  from  perpetuating  r.oeie  very  large  mistakes  and 
oversights.  You  have  won  my  everlasting  gratitude. 

Lt.  Colburn  would  like  to  express  his  deepest  appreciation  to  his 
thesis  partner  Capt.  Ricks  without  whose  professional  expertise,  excel¬ 
lent  background  and  endless  hours  of  work,  a  thesis  of  this  scope  and 
magnitude  could  not  have  been  accomplished.  To  put  it  in  Navy  terms 
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ABSTRACT 


A  Consolidated  AFIT  Database  and  Information  System  (CADIS),  a  cen¬ 
tralized  relational  database  in  third  normal  form,  was  designed  for  use 
by  the  faculty  and  staff  of  the  Air  Force  Institute  of  Technology  (AFIT). 
Information  requirements  were  gathered  by  means  of  an  in-depth 
data/ Information  analysis  at  the  directorate  and  division  level,  and  used 
as  the  basis  of  the  design.  Provided  with  the  design  is  a  highly 
detailed  data  dictionary,  in  four  parts,  and  an  estimation  of  the  approx¬ 
imate  size  of  the  database  itself. 

In  conjunction  with  the  database  design,  all  commercially  available 
Database  Management  Systems  (DBMS)  were  surveyed  and  evaluated  for  use  by 
AFIT.  A  detailed  evaluation  procedure  was  designed,  and  documented,  to 
reflect  the  information  needs  of  AFIT  and  each  DBMS  was  in-turn  judged 
against  it.  The  result  was  a  list  of  commercially  available  DBMSs, 
ranked  according  to  how  they  would  fulfill  the  needs  of  AFIT. 

As  a  result  of  certain  facts  gathered  during  the  data/lnformatlon 
analysis,  several  management  and  organizational  recommendations  were  made 
to  AFIT.  The  aim  of  these  recommendations  was  to  make  the  implementation 
and  management  of  the  database  easier  and  more  effective  and  to  make  the 
database  more  responsive  to  the  users. 

Additionally,  a  system  of  applications  programs  were  designed  for 
I  he  AFIT  Directorate  of  Civilian  Institution  Programs  (AFIT/CI).  Tills 
system  will  allow  efficient  and  easy  access  to  the  data  in  the  database 
by  untrained  or  non-programmer  type  users.  These  programs  were  specifi¬ 
cally  designed  to  provide  an  extremely  friendly  user  interface  between 
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I.  INTRODUCTION 


U  BACKGROUND 

Various  organizations  within  the  Air  Force  Institute  of  Technology 
(AFIT)  have  expressed  a  requirement  for  automated  management  Information 
systems  to  aid  in  the  accomplishment  of  their  mission  requirements.  Each 
year  AFIT  continues  to  expand  and  accept  more  students  and  offer  more 
courses.  Correspondingly  there  has  been  a  rapid  Increase  in  the  amount 
of  paperwork,  and  general  administrative  overhead  associated  with  this 
growth.  This  is  not  unusual  for  an  acadenic  institution  but  the  fact 
that  this  is  also  an  Air  Force  organization  presents  some  unique  problems 
and  situations. 

Presently  each  school  and  department  within  AFIT  maintains  indivi¬ 
dual  files  and  records  on  its  students,  faculty  and  courses  in  an 
arrangement  unique  to  each.  As  a  consequence,  massive  duplication  of  the 
type  of  data  and  in  some  cases  actual  data  has  occurred.  Such  duplica¬ 
tion  is  wasteful  both  in  terms  of  dollars  and  manpower.  Utilization  and 
maintenance  of  these  systems  has  hindered  and  in  many  cases  prevented 
effective  interaction  between  departments  and  management  activities. 

Several  directorates  are  beginning  to  realize,  as  has  the  rest  of 
i he  Air  Force  and  civilian  industry,  that  a  database  management  system. 
If  properly  implemented,  can  alleviate  waste  while  increasing  the  effec¬ 
tiveness  of  everyday  management.  However,  for  each  department  to  imple- 
ment  a  database  management  system  of  their  own  would  not  solve  anything, 
and  to  simply  automate  current  problems  would  be  even  more  wasteful.  In 
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order  Co  avoid  such  a  situation  a  single  integrated  database  specifically 
designed  for  use  within  AFIT  and  fulfilling  the  requirements  of  all  the 
departments  must  be  implemented. 

As  an  example  of  the  extent  of  this  problem,  consider  the  AFIT 
Directorate  of  Civilian  Institution  Programs  (AFIT/CI).  They  are  respon¬ 
sible  for  the  management  of  approximately  5000  AFIT  students  in  civilian 
academic  institutions,  medical  training  and  Education  With  Industry  (EUI) 
programs.  Currently  all  record  keeping  and  retrieval  of  information  is 
performed  manually  with  file  folders  and  hand  scribed  data  sheets. 

in  spite  of  an  ever  increasing  student  load  and  a  corresponding 
decline  in  resources,  growing  emphasis  is  being  placed  on  conservation 
and  "doing  more  with  less".  Requests  for  information  of  all  types  by 
upper  management  are  Increasing  in  number  and  importance  and  are  now  more 
critical  to  the  dally  operation  of  AFIT  than  ever  before.  These  demands 
for  more  accurate  and  timely  information  have  in  general  rendered  present 
methods  all  but  obsolete  and  are  in  fact  quickly  becoming  a  detriment.  A 
simple  request  for  information  concerning  the  student  body,  either  past 
or  present,  is  complicated  by  the  fact  that  several  Independent  sources 
must  be  searched  and  the  results  compiled  before  any  useful  information 
can  be  produced.  The  expenditure  in  time  and  money  is  obviously  tremen¬ 
dous  and  needlessly  wasteful. 

AFIT/CI,  in  conjunction  with  the  remainder  of  AFIT,  must  automate 
their  outdated  method  of  accounting  and  record  keeping  in  order  to  cope 
with  present  and  future  workloads  and  adequately  respond  to  management 
requests  for  that  information  vital  to  the  accomplishment  of  the  AFIT 
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1_.K  PREVIOUS  EFFORTS 

In  1980  an  attempt  was  made  to  test  the  feasibility  for  and  possibly 
of  designing  a  database  which  would  be  suitable  for  use  throughout 
AFIT.(REF  4)  This,  effort  was  aimed  primarily  at  reducing  data  redundancy 
within  AF1T  by  providing  a  central  repository  for  information.  Through 
the  means  of  surveys  and  interviews,  both  resident  schools  were  found  to 
be  maintaining  a  file  system  on  the  students  assigned  to  them  along  with 
Information  about  the  faculty  and  courses  offered. 

This  effort  to  properly  design  and  implement  an  AFIT  database  was 
concerned  primarily  with  the  resident  students,  faculty  and  course  data. 
It  was  to  be  performed  in  two  phases;  gathering  of  data  requirements  and 
design  of  the  database. 

Phase  one  consisted  of  Interviews  with  the  two  AFIT  departments,  the 
School  of  Engineering  (EN)  and  the  School  of  Systems  and  Logistics  (LS), 
in  order  to  help  them  identify  data  requirements  essential  to  the  perfor- 
mance  of  their  mission.  Phase  two  consolidated  these  data  elements  and 
attempted  to  develop  a  combined  database  design  which  was  supposed  to 
fulfill  their  collective  need. 

Several  departments  within  AFIT  were  not  included  in  this  effort, 
they  were:  Commandant  (CC),  Academic  Affairs  (CAE),  Administration  (DA), 
Public  Affairs  (PA),  Academic  Library  (LD),  Research  and  Professional 
Development  (NR),  School  of  Civil  Engineering  (DE)  and  the  Civilian 
Institution  Programs  (Cl).  Of  the  omitted  departments,  one  is  of 


PACE  3 


particular  interest  to  this  thesis.  Civilian  Institution  Programs  (Cl). 
It  was  assumed  that  information  required  by  each  of  these  departments, 
although  somewhat  different,  was  similar  enough  that  they  could  both 
utilize  this  "general"  database  if  they  modified  their  data  requirements 
to  fit  it. 

Since  its  completion  in  1980,  very  little  has  been  done  in  the  area 
of  actual  implementation.  Various  portions  of  the  proposed  database  have 
been  set  up  for  limited  use  by  students  in  the  engineering  school,  pri- 
marily  to  give  students  experience  in  interacting  with  an  actual  data- 
base.  For  reasons  beyond  the  scope  of  this  project,  a  full  scale  imple¬ 
mentation  of  this  database  has  yet  to  materialize,  be  loaded  with  mean¬ 
ingful  data,  and  utilized  throughout  AFIT. 

The  shortcomings  of  the  earlier  effort  are  many  and  varied  espe¬ 
cially  in  light  of  current  knowledge  and  goals.  Those  directorates  which 
were  not  included  in  the  original  database  design  have  started  to  move 
out  on  their  own  and  seek  automated  support  because  of  growing  workloads. 
Consequently,  they  have  been  somewhat  reluctant  to  participate  in  a  data¬ 
base  which  does  not  accurately  and  completely  fulfill  their  needs.  In  at 
least  one  Instance,  a  directorate  (AFIT/RR)  h/s  already  acquired  a  regis¬ 
trar  oriented  file  management  system  and  is  currently  prepared  to  utilize 
It  on  a  dally  basis.  It  is  not,  however,  a  database  management  system 
and  cannot  conform  to  the  overall  AFIT  goal  of  a  single  integrated  data¬ 
base  . 

The  first  project  was  narrow  in  scope  and  did  not  include  such  vital 
areas  as  security  and  privacy  of  the  database  and  its  data,  backup  and 


recovery  of  the  database,  administration  of  the  database  and  the  need  for 
a  facility  to  handle  non  routine  queries  and  reports.  If  successful 
implementation  of  a  database  for  general  use  within  an  organization  such 
as  AFIT  is  to  be  accomplished,  these  items  irt  aosolutely  essential  and 
must  be  carefully  addressed  before  the  first  piece  of  data  is  assembled 
or  the  resulting  database  will  not  be  as  effective  or  useful  as  it  could 
be. 

l_.2.  SOLUTION  AND  APPROACH 

The  purpose  of  this  thesis  is  basically  to  pick  up  where  the  1980 
thesis  project  left  off,  plus  expand  it  to  cover  other  essential  areas 
not  previously  addressed.  The  design  of  a  consolidated  integrated  data** 
base  suitable  for  use  by  all  departments  within  AFIT,  a  recommendation 
for  a  host  DBMS,  and  the  design  of  an  Information  system  suitable  for 
fulfilling  the  requirements  of  AFIT/CI  is  the  desired  end  product. 
Because  the  concept  of  a  central  database  has  already  been  recognized  and 
accepted  within  AFIT,  now  is  the  time  to  tackle  and  solve  the  additional 
issues  associated  with  such  a  project. 

Some  replication  of  the  effort  Involved  in  the  original  thesis  will 
be  necessary  because  both  of  the  schools  originally  interviewed  must  be 
contacted  again  in  order  to  revalidate  their  data  requirements.  Also, 
the  departments  responsible  for  non-resident  programs  and  those  depart¬ 
ments  not  originally  contacted  in  the  first  survey  will  be  given  the 
opportunity  to  include  their  data  requirements.  Only  after  this  is  com¬ 
pleted  will  there  be  a  solid  core  of  data  elements  from  which  an 
integrated  database  can  be  built  and  effectively  implemented. 


Concurrent  with  the  above  actions,  steps  will  be  initiated  to  review 
all  available  literature  on  database  management  systems  and  their  capa¬ 
bilities*  Each  department  will  also  be  asked  to  state  what  they  want 
from  a  database  management  system  and  what  they  would  like  to  be  able  to 
do  with  one*  These  desires  will  be  combined  with  the  functions  required 
to  perform  basic  database  manipulation  tasks  and  used  as  the  criteria  for 
a  critical  analysis. 

As  many  DBMSs  as  can  be  located  and  are  commercially  or  currently 
available  within  AFIT  or  the  federal  government  will  be  investigated.  A 
predesignated  set  of  criteria  will  be  established  with  which  each  DBMS 
will  be  judged  based  on  available  information.  Criterion  will  include 
such  things  as  availability,  cost,  compatibility  with  existing  hardware, 
reliability,  backup  and  recovery  features,  security  and  query  capabili¬ 
ties.  Each  DBMS  will  be  assigned  a  set  of  weighted  values  according  to 
how  well  it  fulfills  each  item.  The  results  of  this  evaluation  will  then 
be  ordered  according  to  the  totals  compiled  for  each  database  system  with 
the  highest  scoring  ones  being  considered  primary  candidates  for  imple¬ 
mentation. 

The  results  will  be  documented,  included  in  this  thesis  writeup  and 
also  presented  as  a  set  of  formal  recommendations  to  the  AFIT  Computer 
Configuration  Board  (CCB)  for  their  consideration  and  decision  as  to 
which  system  should  be  utilized.  The  emphasis  is  on  finding  the  DBMS  or 
DBMSs  from  all  those  currently  available,  either  in-house  or  commer¬ 
cially,  which  can  accomplish  the  Job  in  the  most  economical  and  efficient 
manner. 
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Included  with  these  recommendations  will  be  a  normalized  database 


schema  which  can  be  directly  implemented.  This  structure  will  insure 
minimal  data  redundancy,  provide  ease  of  access  and  preserve  as  many  of 

the  data  dependencies  as  possible  while  maximizing  data  reliability  and 
Integrity. 

Should  a  DBMS  which  is  not  currently  available  be  chosen,  the 
overall  Ira piemen tat ion  process  of  AF1T/CI  requirements  will  have  to  be 
amended.  If  this  situation  arises,  an  available  system  which  closely 
matches  the  chosen  one's  architecture  could  be  used  to  develop  as  much 
application  software  as  possible.  In  any  event,  a  fully  documented 
''paper”  design  of  the  applications  programs,  including  a  Functional 
Description  (FD),  detailed  program  Specifications,  and  all  data  require¬ 
ments  needed  for  inclusion  into  the  database  will  be  completed. 

The  applications  programs  to  be  designed  will  provide  AFIT/CI  easy 
access  to  the  database  on  a  daily  basis,  thus  beginning  the  move  toward 
the  replacement  of  the  current  and  outdated  manual  system.  A  routine 
query  capability,  the  production  of  standard  reports  and  documents  and 
the  ability  to  answer  unusual  or  ad-hoc  questions  initiated  by  higher 
management  are  among  the  desired,  and  currently  unavailable,  capabili¬ 
ties. 


The  design  of  the  application  system  will  be  based  upon  the  tech¬ 
niques  of  structured  analysis  and  design.  This  will  insure  a  complete 
top-down  design  and  a  total  understanding  of  their  operation  so  that  the 
person(s)  who  follow  this  thesis  with  the  implementation  of  the  database 
and  writing  of  the  applications  programs  will  be  able  to  code,  and  easily 
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maintain  the  system  as  required. 

Of  prime  importance  to  this  project  is  not  only  a  complete  AFIT 
database  and  a  comprehensive  design  of  the  AF1T/CI  applications  programs, 
but  a  complete  set  of  documentation  for  the  procedures  used  to  select  the 
DBMS.  It  is  hoped  that  this  thesis  will  serve  as  a  guide  to  others  who 
wish  to  choose  ai\d  Implement  a  database  management  system  where  none 
currently  exists,  as  well  as  be  an  exemplary  use  of  software  engineering 
techniques  for  the  design  of  any  applications  programs. 

i#2‘  assumptions 

There  are  some  Important  assumptions  embodied  in  this  thesis.  They 

are: 

(1)  .The  application  of  automated  database  techniques  offer  the  optimal 

solution  to  both  the  long  and  near  term  AFIT  situations. 

(2)  The  Information  management  problems  of  AFIT  are  real  and  require  a 
timely  and  adequate  solution  in  order  to  meet  mission  requirements. 

(3)  Currently  available,  of f-the-shelf  hardware  and  software  can  be 
used.  Some  of  which  may  or  may  not  currently  reside  within  AFIT. 

Assumption  one  is  the  primary  motivating  force  behind  this  thesis 
effort.  The  fact  that  an  information  management  problem  exists  and  has 
been  recognized  throughout  all  levels  of  AFIT  is  evidenced  by  some  key 
eventB.  These  Include  the  Initial  AFIT  database  thesis  by  Lt .  Allred 
(REF  A),  successive  establishment  and  work  on  the  AFIT/EN  database  by  Dr. 
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Lamont,  Che  current  emphasis  by  the  Computer  Configuration  Board  (CCB) 
and  the  Computer  Resources  division  (AFIT/ACD)  concerning  information 
management,  plus  the  comments  received  from  the  faculty  and  staff. 

A  major  assumption  in  this  thesis  is  that  automated  database  tech¬ 
niques  offer  the  optimal  solution  to  AFIT'a  near  and  long  term  informa¬ 
tion  management  problems.  In  this  context,  “automated  database  tech- 
niques“  is  used  to  mean  generalized  database  management  software  designed 
to  run  on  a  computer,  as  opposed  to  non-automated  techniques  such  as 
manual  filing,  or  certain  special  automated  systems  such  as  file  manage¬ 
ment  systems. 

While  the  distinction  between  automated  and  manual  "database" 
methods  is  obvious,  the  distinction  between  database  management  systems 
and  file  management  systems  is  not.  In  general,  a  database  system  is 
data  oriented  while  the  traditional  file  system  is  function  oriented. 
File  management  systems  directly  relate  fl’es  to  specific  programs. 
Their  arrangement,  distribution  on  storage  devices,  and  organization  are 
developed  solely  to  achieve  optimal  program  performance.  Data  is  nor¬ 
mally  accessed  via  an  application  program  only  and  the  only  growth  which 
occurs  is  in  terms  of  data  volume.  Unfortunately,  this  is  a  dead  end 
situation  because  data  in  one  file  and  for  one  set  of  programs  is  gen¬ 
erally  not  available  or  compatible  with  other  programs.  Also,  common 
data  in  several  files  produces  considerable  data  redundancy  and  data 
updated  or  changed  on  one  file  will  not  necessarily  be  updated  accord¬ 
ingly  in  the  other  files  which  also  contain  it.  (REF  7) 
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A  database,  on  the  other  hand,  is  designed  to  provide  generality, 
flexibility,  and  extensibility,  both  in  the  representation  of  the  various 
records  and  in  the  files  which  comprise  it,  A  database  is  meant  to  be  a 
dynamic  information  resource  to  be  drawn  upon  by  a  growing  and  changing 
community  of  users  and  not  a  preestablished  set  of  files  with  rigid  for- 
mat  and  a  fixed  relationship  to  the  application  programs,  (REF  7) 

Although  it  seems  clear  that  a  Management  Information  System  (MIS), 
which  has  a  database  as  its  basis,  can  be  a  logical  solution  to  an  infor¬ 
mation  management  problem,  one  must  be  sure  that  there  are  sufficient 
economic  rewards  to  offset  the  associated  costs  in  manpower,  software  and 
hardware.  Unfortunately,  there  are  no  set  equations  which  can  be  used  to 
quantitatively  measure  the  potential  that  a  database  holds  for  a  given 
organization.  However,  some  general  situations  have  been  identified  by 
industry  which  point  toward  the  desirability  of  a  database  in  specific 
situations.  In  general,  situations  in  which  on-line  inquiry  capability 
is  required,  and  where  there  will  be  growth  in  data  volume  and/or  data 
types  and  a  corresponding  wide  community  of  interest  in  database  applica¬ 
tions,  Indicate  the  potential  and  desirability  of  a  database  system. 
Currently  all  of  these  factors  are  present  and  readily  identifiable 
within  AFIT.  In  addition  to  these  general  reasons  for  using  automated 
database  techniques,  there  are  some  specific  advantages  to  AFIT.  (KEF  ti, 
p  459) 

The  first  and  major  advantage  of  a  DBMS  is  that  of  real-time,  on¬ 
line  data  accessibility.  Routine  queries,  reports  and  ad  hoc  queries  can 
be  performed  Interactively  by  non-programmers  in  minutes  rather  than  the 
hours  or  days  normally  associated  with  manual  or  less  automated  methods. 
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(REF  15,  p  425)  In  addition  to  responsiveness,  another  aspect  of  a  DBMS 
is.  the  existence  of  a  complete  query  capability.  This  means  that  a  DBMS 
has  the  ability  to  answer  complex  questions  using  both  primary  and  secon¬ 
dary  data  characteristics,  plus  perform  certain  calculations  and  logical 
functions  on  and  against  the  data  according  to  the  needs  of  the  indivi¬ 
dual  user.  (REF  12,  p  35) 

A  second  advantage  of  DBMS's  is  their  potential  to  minimize  cost. 
This  Includes  minimizing  total  data  storage  requirements,  software  and 
data  redundancies,  programming  efforts  due  to  data  changes,  training 
costs  and  the  overall  amount  of  paper  associated  with  other  automated 
systems.  Storage  requirements  are  minimized  in  two  main  ways.  First,  by 
consolidating  all  common  data  formerly  replicated  in  various  places,  and 
second,  by  physically  representing  data  in  storage  differently  than  the 
logical  representation  which  the  application  programmer  or  end  user 
requires.  Software  redundancies  are  minimized  because  the  functions  of 
data  collection,  verification,  retrieval,  security,  storage  and  mainte¬ 
nance  are  all  handled  by  the  DBMS  instead  of  on  an  application  by  appli¬ 
cation  basis.  (REF  15) 

Reprogramming  efforts  due  to  data  changes  are  minimized  because  of 
data  independence,  limited  accessibility,  currency  and  consistency.  Data 
independence  means  that  each  application  program  logically  views  the  data 
in  terms  of  its  own  needs  and  may  be  entirely  independent  of,  or  isolated 
from,  those  used  by  other  applications  or  users.  Limited  accessibility 
implies  not  only  separate  logical  views  of  the  data  but  a  set  of  limita¬ 
tions  on  what  functions  can  be  performed  on  the  data  which  may  be  common. 
This  means  only  certain  users  have  the  right  to  create,  modify  or  destroy 


certain  data,  thus  preventing  unauthorized  applications  or  personnel  from 
changing  or  damaging  important  data,  either  intentionally  or  inadver¬ 


tently.  Currency  refers  to  the  fact  that  alterations  in  the  actual  phy¬ 
sical  file  are  performed  only  by  the  DbMS.  When  it  is  determined  that  a 
change  should  be  made  in  the  data  or  in  its  logical  or  physical  represen¬ 
tation,  the  DBMS,  under  the  direction  of  the  Database  Administrator 
(DBA),  performs  all  appropriate  changes.  The  results  are  more  current 
and  accurate  data  for  the  community  of  users  which  need  it.  Training 
costs  are  reduced  because  the  existence  of  powerful  user  languages  avail¬ 
able  on  many  DBMS#s  means  people  are  no  longer  required  to  have  expensive 
and  lengthy  classes  in  programming  and  computer  science  in  order  to  use 
the  database.  These  languages  are  designed  to  permit  relatively 
untrained  users  to  query  and  update  data  in  a  database,  manipulate  data, 
and  generate  reports  in  specific  formats  as  dictated  by  their  needs. 
Finally,  paper  usage  is  reduced  tremendously  because  data  traditionally 
"stored"  on  large  printouts  is  now  left  on  the  computer  and  only  called 
out  when  needed.  A  DBMS  also  allows  users  to  only  access  the  exact  por¬ 
tion  of  the  entire  database  they  wish  to  see,  thus  freeing  them  from  wad¬ 
ing  through  mountains  of  reports  and  other  useless  printed  data.  (KRF  12, 
P  32-34) 

A  third  advantage  of  a  DBMS  is  its  ability  to  represent  the  inherent 
structure  of  the  data  by  logically  modeling  the  relationship( s)  which 
exist  among  data  of  differing  types.  This  translates  into  an  ability  tor 
each  user/application  program  to  have  its  own  view,  which  means  everyone 
can  see  the  data  In  the  most  natural  and  easily  used  form,  and  not  have 
the  format  dictated  by  the  limitations  of  the  computer.  (RFF  lb) 
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A  fourth  advantage  Is  the  ease  of  growth.  Many  DBMS's  allow  for 
easy  restructuring  of  the  database  as  new  data  types  and  new  applications 
are  identified.  Restructuring  of  the  data  is  possible  often  without 
rewriting  existing  applications  programs  or  affecting  other  data  which  do 
not  utilize  the  restructured  portion  of  the  database.  (REF  15,  p  23) 

A  fifth  advantage  of  DBMS's  is  the  inherent  ability  to  use  integrity 
checks.  This  means  that  although  the  database  contains  data  employed  by 
many  different  users,  the  data  items  and  associations  between  data  them 
will  not  be  destroyed.  Other  integrity  checks  involve  insuring  that  data 
values  conform  to  certain  specified  rules,  e.g.  are  constrained  to  lie 
within  certain  ranges  or  values.  (REF  5) 

A  sixth  advantage  of  a  DBMS  is  tunabllity.  Because  real-time/on¬ 
line  data  access  is  such  a  key  consideration,  the  time  it  takes  a  system 
to  respond  is  of  vital  importance.  Once  the  database  has  been  esta- 
bllshed,  users  will  begin  to  want  different  services  from  the  DBMS  as 
they  become  familiar  with  the  many  ways  the  system  can  be  used  or  as 
applications  programs  evolve.  Such  changes  can  have  a  major  impact  on 
the  organization  and  storage  of  data  and  ultimately  on  the  response  time 
of  the  DBMS.  Therefore,  the  ability  to  tune  or  improve  the  performance 
of  the  database  is  very  important.  (REF  15) 

A  seventh  advantage  of  a  DBMS  are  the  ancillary  benefits  that  accrue 
to  organizations  which  utilizes  them.  Since  the  creation  and  administra¬ 
tion  of  a  database  is  channeled  through  one  agency,  the  DBA,  the  database 
itself  is  subjected  to  standardization.  Just  as  in  a  standard  language, 
standardization  of  a  data  simplifies  its  use,  instruction,  interprets- 
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cion,  problem  formulation  and  programming.  (KEF  12,  p  35) 


Security  is  another  benefit,  which  to  some  organizations  is  the  most 
important.  Besides  the  authority  required  by  the  user  to  access  the 
database  in  general,  there  is  also  specific  authority  required  to  use  a 
given  logical  view.  Also  a  further  level  of  protection  inherently 
resides  in  the  logical  view  itself,  thus  restricting  portions  of  the 
database  from  unauthorized  users.  Additionally,  in  some  DBMS°s  security 
controls  can  be  even  placed  on  individual  data  elements.  It  must  be 
emphasized,  however,  that  no  system  is  totally  secure,  but  the  above 
measures  do  exist  to  make  life  as  difficult  as  possible  for  persons  who 
would  unintentionally  or  by  design  attempt  to  compromise  the  security  of 
the  database.  (REF  12,  p  35-36) 

The  conditions  which  make  the  use  of  a  DBMS  advantageous  plus  the 
general  desirability  of  such  a  system  are  present  at  AFIT  ri>.  r  now. 
This  fact,  coupled  with  the  power  and  many  advantages  of  DBMSss  serves  to 
support  assumption  number  two.  Assumption  three  is  baseu  on  the  power, 
sophistication  and  advantages  of  current  DBMS  technology.  Civen  the 
current  state  of  the  art  of  off-the-shelf  DBMS  systems,  the  cost/benefit 
ratio  of  using  an  existing  system  versus  developing  one  in  house  is 
heavily  in  favor  of  using  an*-existiug  system. 

CURRENT  KNOWLEDGE 

(1)  Previous  work  on  a  consolidated  AFIT  database  has  been  performed, 
primarily  within  AFIT/EN  and  AFIT/ACD,  and  will  be  used  as  a  start¬ 
ing  point. 

(2)  Some  preliminary  data  concerning  required  outputs,  reports,  data 
elements  and  procedures  has  been  accumulated  by  AFIT/CI  personnel. 
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(3)  The  AFIT/CI  project  has  been  entered  into  the  AFIT  ADP  planning  pro¬ 
cess  and  resources  are  available  for  commitment  to  this  project. 

(4)  Commercially  available  systems  (both  hardware  and  software) 
presently  exist  which  can  satisfy  this  requirement  if  configured 
correctly. 

(3)  Data  security  and  backup  and  recovery  for  the  overall  system  is  a 
primary  concern  and  must  be  adequately  addressed. 

(6)  Some  attempt  has  been  made  on  the  part  of  AFIT  to  consolidate  the 
information  requirements  of  all  of  its  directorates. 


II  DATA  REQUIREMENTS  ANALYSIS 


2.  PURPOSE 


The  purpose  of  this  requirements  analysis  is  to  gather  as  much  data 
as  possible  from  each  of  the  AFIT  directorates  and  their  data  systems, 
gain  a  thorough  understanding  of  what  information  they  need  to  do  their 
job,  and  consolidate  it  into  the  smallest  functional  set  possible.  Addi¬ 
tionally,  an  attempt  will  be  made  to  formulate  some  conclusions,  based  on 
the  total  byte6  of  data,  as  to  the  amount  of  memory  which  would  be 
required  to  allow  the  database  to  function  acceptably.  The  data  to  be 
analyzed  will  include  individual  data  elements  and  their  size,  all 
appropriate  reports/documents,  information  sources  and  destinations,  and 
departmental  interfaces  for  all  of  AFIT. 

This  analysis  will  be  an  expansion  of  the  limited  one  conducted  as 
part  of  the  previous  thesis.  (REF  4)  However,  this  time,  all  of  AFIT  and 
not  just  the  Schools  of  Engineering  (EN)  and  Logistics  and  Systems  (LS) 
will  be  Included.  It  is  intended  that  the  results  of  this  study  will 
provide  the  most  complete  and  concise  set  of  data  requirements  yet  com¬ 
piled.  Once  this  has  been  accomplished,  the  results  can  be  used  to  pro¬ 
ject  the  minimum  processing  support  (hardware,  system  software  and 
memory)  plus  the  type  and  functions  of  possible  database  management  sys¬ 
tems.  When  considered  together,  these  factors  will  provide  a  database 
with  sufficient  access,  protection  and  utility  to  be  truly  useful  at 
AFIT. 
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By  gathering  the  types  of  data  described  above  and  combining  it  with 
the  frequency  of  use,  security  requirements  and  how  it  is  used,  a  clear 
and  accurate  understanding  of  the  function,  oi  jc-  i  Ives,  responsibilities 
and  procedures  of  each  department  can  be  achieved.  This  will  aid  the 
AF1T  Computer  Configuration  Board  (CCB),  the  group  which  has  been  tasked 
by  AFIT/CC  to  Implement  a  database  management  system,  in  the  completion 
of  this  goal.  It  has  been  requested  by  the  chairman  of  the  CCB  that  this 
analysis  be  supplied  to  the  CCB  for  their  consideration  and  action  when 
completed . 

If  the  individual  departmental  data  requirements  cannot  be  defined 
or  the  requirements  remain  ambiguous,  the  resulting  database  will  not  be 
able  to  solve  any  of  AFITs  problems,  but  merely  duplicate  them  in  an 
automated  environment.  Therefore,  the  accuracy  of  this  analysis  is 
vital,  not  only  to  this  project,  but  to  the  AFIT  goal  of  implementing  a 
Consolidated  AFIT  Database  and  Information  System  (CADIS). 

2^1_.  PROCEDURE 

In  general  the  procedure  to  be  followed  during  this  analysis  will  be 
one  of  seeking  out  and  gaining  an  understanding  of  any  information  which 
presently  exists  within  AFIT  which  might  be  applicable  to  a  consolidated 
database.  This  material  will  be  studied  to  find  out  how  it  correlates, 
and  then  arranged  into  a  format  which  is  easy  to  comprehend  and  handle. 
The  final  step  will  be  the  expansion/shrinking  of  this  list  by  including 
the  requirements  from  each  of  the  departments  throughout  AFIT. 
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A  thorough  working  knowledge  of  any  data  requirements  which 
currently  exist  is  important  and  must  be  achieved  prior  to  the  solicita¬ 
tion  of  any  new  data.  This  will  offer  some  good  clues  as  to  the  inten¬ 
tions  and  desires  of  the  institute  and  eliminate  numerous  wasted  hours  in 
rediscovering  old  material.  It  is  already  known  that  at  least  two  AFIT 
departments  have  some  kind  of  studies,  reports,  etc.  on  hand  which  might 
pertain  to  general  data  requirements.  AF1T/RR  is  completing  the  imple¬ 
mentation  of  a  commercial  data  management  system  specifically  designed  to 
perform  registrar  functions.  They  have  defined  the  data  elements  they 
require,  set  up  the  appropriate  files  and  are  completing  the  applications 
programs  which  will  support  their  operations.  Additionally,  the  AFIT 
Data  Automation  Division  (AFIT/ACD)  has  accumulated  some  general  informa¬ 
tion  concerning  the  general  data  requirements  which  should  be  Included  in 
an  institute  wide  database.  Available  data  from  these  sources  will  be 
collected,  reviewed  for  completeness,  consolidated  and  used  as  a  basis 
for  establishing  the  total  data  requirements  for  all  of  AFIT. 

Once  the  on-hand  data  has  been  collected  and  restructured  into  a 
more  readable  format,  the  process  of  presenting  it  to  the  remainder  of 
AFIT,  in  order  to  obtain  any  additions/deletions,  will  begin  in  earnest. 
The  heads  of  each  of  the  directorates  and  schools  will  be  asked  to  supply 
any  Information  they  can  which  would  lead  to  a  com  Pi  ete  definition  of  the 
data  requirements  specific  to  their  departments. 

In  addition  to  the  departments  not  considered  in  the  original  thesis 
project  (REF  4),  AFIT/LS  and  AFIT/EN  will  be  asked  to  revalidate  their 
previous  input.  Also  to  be  included  in  this  analysis  will  be  AFIT/ACD 
and  AFIT/CAE.  During  the  meetings  with  the  directorate  heads,  or  their 
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representative^) ,  the  contents  of  the  EN  database  and  RK  registrar  sys¬ 
tem  will  be  explained  and  discussed.  It  is  anticipated  that  in  so  doing, 
common  areas  may  be  discovered  as  well  as  new  ideas  identified. 

Of  primary  interest  is  the  data  elements/information,  already  in  the 
EN  database,  which  each  department  can  use  "as  is",  without  modification; 
and  that  data  which  can  be  used  if  modified  (if  so,  what  needs  to  be  done 
must  be  spelled  out).  By  identifying  these  elements  early  in  the 
analysis,  the  factor  of  commonality  can  be  used  to  its  greatest  advan¬ 
tage.  The  earlier  this  can  be  done,  the  less  time  is  wasted  in  research 
and  meetings,  plus  the  final  product  is  enhanced  and  made  more  efficient. 

Secondarily,  each  functional  area  will  be  asked  to  supply  all 
appropriate  information  pertaining  to  any  data  elements/information  they 
require  but  which  are  not  currently  accounted  for.  This  input  will 
include  the  sources  and  destinations  of  their  data,  the  major 
reports/documents  used,  the  frequency  of  data  access  and  a  complete 
description  of  all  the  data  elements  which  compose  them  (this  includes 
definition,  size  and  functional  dependencies).  another  item  which  is 
extremely  important  and  can  only  be  supplied  by  the  departments  is  an 
estimation  of  the  quantity  &  size  of  each  piece  of  Information  (or 
record).  This  will  to  be  used  later  estimate  the  overall  size  of  the 
database . 

data  gathering  has  been  accomplished,  the  results  will  be  reduced 
into  the  smallest  "functional"  or  useful  set  possible,  any  cu.n.jon  (or 
near  common)  reports/documents  Identified  and  the  major  information 
Interfaces  shown.  Each  data  element  will  be  listed  alphabetically,  and 
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by  record,  along  with  a  description  and  its  length  for  later  use.  In 
order  to  enhance  the  utility  of  this  information,  a  sec  of  tables  (rela¬ 
tions)  will  be  constructed,  which  represents  only  one  possible  database 
schema,  and  presented  to  the  CCB. 


2.2.  RESULTS  and  CONCLUSIONS 

The  process  of  conducting  an  in-depth  requirements  analysis  has  pro¬ 
vided  a  great  deal  of  data  and  knowledge  about  both  the  overall  and 
specific  information  requirements  of  AFIT.  In  order  to  adequately 
present  this  enormous  amount  of  information,  gathered  from  Interviewing 
approximately  40  people  over  a  four  month  period,  the  data  has  been 
grouped  into  some  general  categories.  These  categories  include  the  basic 
assumptions  and  ground  rules  which  governed  the  Interviews,  the  actual 
results  of  the  Interviews,  any  unidentified  or  incomplete  data  require¬ 
ments,  recommendations  for  the  use  of  certain  data  and  structures,  recom¬ 
mendations  for  the  management  and  organisation  of  the  Consolidated  AFIT 
Database  and  Information  System  (CADIS),  an  implementation  plan,  possible 
Interfaces  to  CADIS,  and  a  discussion  of  the  overall  structure  ana  format 
of  the  database  itself. 


2^. Ceneral  Assumptions  of  the  Data  Analysis 

The  basic  assumption,  as  has  already  been  stated,  is  that  the  previ¬ 
ous  thesis  by  Lt.  Allred  (KEF  4)  would  serve  as  a  basis  or  starting 
point.  By  using  his  results  lt  would  be  possible  to  quickly  gain  a  great 
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deal  of  insight  into  the  nature  of  the  requirements  for  the  remainder  of 
AFIT.  Another  assumption,  and  one  perhaps  just  as  basic,  was  that  a  sin¬ 
gle  consolidated  and  integrated  database  would  best  serve  the  needs  of 
AFIT.  This  does  however.  Include  a  distributed  database,  or  one  whose 
data  resides  on  more  than  one  computer  and  has  a  single  structure  and 
definition,  but  specifically  excludes  multiple,  independent  database  sys¬ 
tems. 


The  general  guidelines  adopted  in  regards  to  the  overall  conduct  of 
the  requirements  survey  and  analysis  were  designed  so  as  not  to  impede  or 
restrict  the  type  or  nature  of  the  input.  Users  were  not  questioned  as  to 
why  a  particular  piece  of  information  was  needed,  only  how  it  would  be 
used.  Therefore,  all  requirements  were  considered  valid  for  possible 
inclusion  the  database  design.  This  ultimately  resulted  in  an  analysis 
which  was  of  a  greater  depth  than  anticipated  and  more  inclusive  than  any 
done  previously. 

The  other  procedural  guideline  which  was  used  also  concerned  the 
data  requirements.  Requirements  which  were  found  to  be  incomplete,  not 
clearly  defined  or  beyond  the  scope  of  the  final  project  could  not  be 
Included  in  the  database  design.  However,  in  the  interest  of  complete¬ 
ness  and  accuracy,  all  such  requirements  are  listed  separately,  along 
with  who  identified  it  and  an  explanation  as  to  why  it  was  not  included. 
Therefore,  those  who  follow-up  this  project  with  a  full  scale  implementa¬ 
tion  will  have  some  idea  as  to  the  areas  whi; h  require  further  attention 
because  all  the  AFIT  Information  requirements  now  known  will  be  recorded 
in  a  single  place  with  no  question  as  to  who  needs  what. 
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2^._2 •  2_.  Results  of  the  Surveys 

On  3  July  1982  the  AFIT  Computer  Configuration  Hoard  (CCU)  offi¬ 
cially  asked  that  the  results  of  this  project  be  formally  presented  to 
them.  Dr.  Uolaver,  AFIT/NR,  in  turn  signed  a  letter  on  16  July  1982 
(Appendix  IA)  which  officially  announced  the  impending  analysis  and 
requested  the  cooperation  of  ull  directorates.  This  letter  in  effect 
granted  the  authority  necessary  to  allow  an  AFIT  wide  data  requirements 
survey  and  analysis.  As  a  result  all  the  AFIT  directorates  and  schools 
were  contacted,  interviewed  and  provided  an  opportunity  to  submit  their 
individual  requirements. 

£.2^.  Synopsis  of  the  Procedure 

Using  the  data  elements  identified  in  the  previous  thesis  (REF  4), 
along  with  those  already  being  used  within  the  AFIT/RR  registrar  system, 
a  worksheet  was  prepared  for  use  within  the  interviews  (Appendix  18) .  It 
was  felt  that  this  would  aid  people  by  serving  as  a  "mind  jogger"  and 
give  them  a  general  idea  of  what  was  available,  what  was  possible  and 
what  was  being  sought.  In  the  course  of  ar  interview,  each  directorate 
representative  was  given  a  brief  background  of  the  project  and  a  summary 
of  relevant  past  events.  The  worksheets  were  then  presented  and  their 
content  and  intent  explained.  Participants  were  requested  to  use  the 
sheet  as  a  "scratch  pad"  and  signify  those  data  elements  and  relations 
they  could  either  use  with  no  changes,  use  if  modified  as  they  so  indi¬ 
cated  or  hud  no  need  for.  Additionally,  they  were  asked  to  somehow  iden¬ 
tify  any  new  information  which  might  be  peculiar  to  them  and  would  be 
needed  to  make  the  database  a  useful  utility  for  their  organization. 
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Each  department  was  requested  to  be  as  expedient  and  complete  as 
possible  but  encouraged  to  take  as  much  time  as  was  necessary  to  fully 
cover  their  directorate.  The  individual  results  are  listed  in  Appendix 
1C  by  respondent. 

2^2  Ceneral  Comments  on  the  Interviews 

The  reception  by  the  vast  majority  of  people  contacted  in  regards  to 
this  project  was  enthusiastic  and  supports  o.  however,  most  expressed 
frustration  and  dissatisfaction  over  the  inability  to  maintain  and  effec¬ 
tively  use  the  Information  required  by  their  organization.  Current  func¬ 
tions  and  responsibilities,  plus  current  and  projected  requirements  and 
problems  were  all  discussed  freely  and  openly  in  a  professional  and 
receptive  manner. 

Almost  universally,  it  was  expressed  that  CADIS  was  desperately 
needed  and  that  once  Implemented,  would  go  a  long  way  toward  alleviating 
some  critical  problems,  assuming  certain  principles  were  kept  in  mind. 
Foremost  of  these  was  that  such  a  system  musi  provide  easy  access  to  the 
database  plus  the  ability  to  conveniently  query  and  manipulate  the  data 
as  need  be.  Applications  programs  and  their  subsequent  support  was  gen¬ 
erally  not  desired  because  an  adequate  DBMS  could  give  them  greater  flex¬ 
ibility  through  the  query  facility  and  report  generator  without  the  cost 
of  software  development  and  maintenance.  When  discussing  the  need  for 
reports  and  other  required  documents,  it  was  found,  as  expected,  that  if 
these  facilities  were  present,  the  need  for  many  paper  records  and  inter 
departmental  reports  would  vanish. 
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The  School  of  Engineering  (AFIT/EN)  and  the  School  of  Systems  and 
Logistics  (AFIT/LS)  were  interviewed  in  greater  depth  than  other  areas 
because  some  of  the  basic  data  elements  used  were  a  result  of  the  previ¬ 
ous  in-depth  analysis.  (REF  4)  It  was  felt  that  the  individual  depart¬ 
ment  heads  should  be  contacted  so  they  could  revalidate  their  overall 
requirements.  In  most  cases  this  resulted  in  a  great  deal  of  new  infor¬ 
mation  as  well  as  modifications  to  others* 


tr 


2.2^ .J>.  Overall  Data  Requirements 

The  purpose  of  this  section  is  to  present  an  overall  picture  ot  tne 
results  of  the  data  requirements  analysis.  They  will  be  discussed  in 
general  terms  but  are  more  clearly  and  accurately  presented  in  chart  form 
in  appendix  IIC. 

The  overall  goal  of  this  project  was  to  identify  all  the  data 
requi rements  and  design  an  Integrated  database  which  would  reflect  all 
the  current  needs  of  AFIT.  In  reality  however,  some  directorates 
presented  data  which  they  did  not  elaborate  upon  nor  was  there  time  to 
del Ine  completely.  Therefore  what  was  actually  gathered  was  a  solid  core 
of  highly  common  data,  which  if  implemented  in  a  timely  manner,  should 
satisfy  a  very  large  amount  of  AFIT's  information  requirements.  This 
reasoning  is  based  on  the  fact  tliai  almost  all  of  the  requirements 
expressed  revolved  around  a  sub  set  ot  the  overall  data.  This  'central 
core"  consists  of  general  student,  t acuity  and  .-.tali  data  plus  several 
smaller  relations  which  provide  necessary  aau  more  detailed  additional 
information. 
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Another  goal  of  those  interviews  was  to  gainer  a  list  of  ail  the 
reports  and  documents  which  were  used  within  AFIT.  However,  tills  was 
found  to  have  been  completed  by  AFIT/ACD  along  with  data  flow  diagrams 
for  the  entire  organization.  These  may  be  found  in  the  1981  A  FIT  Al>P 
Master  Plan  (REF  3). 

The  overall  structure  of  the  database  can  be  found  in  the  torm  oi  a 
diagram  in  appendix  IC.  This  chart  represents  each  of  the  relations 
identified  to  date  plus  a  depiction  of  the  most  important  logical  associ¬ 
ations  between  them.  A  line  connecting  two  relations  means  that  there  ia 
at  least  one  common  attribute  between  them  and  that  there  is  also  a  mean¬ 
ingful  logical  connection  between  the  two.  All  student  and  staff  data  is 
accessed  by  the  Social  Security  Account  Number  ( S SAN )  of  the  person  ut 
Interest. 

Many  attributes  in  these  relations  are  codes  or  snort  names,  but  a 
user  can  obtain  full  titles  or  expanded  information  on  most  of  these 
codes  or  abbreviations.  This  is  accomplished  by  using  a  logical  connect¬ 
ing  code  and  retrieving  the  associated  full  description,  or  in  some  cases 
by  referring  to  the  data  dictionary. 

The  chart  in  Appendix  IC  denotes  no  other  meaning  than  that 
described  above.  The  size  of  a  figure,  nor  the  length,  nor  the  number  of 
lines  implies  any  information. 

More  information  on  the  content  of  the  database  can  be  found  in 
appendices  IU,  IE,  IF,  IC  and  III.  The  first  four  documents  essentially 
comprise  a  highly  detailed  data  dictionary,  wMlo  the  fifth  shows  the 
database  size  estimates.  Appendix  IU  gives  a  functional  description  of 


each  of  Che  relations  on  Che  chart  along  wlch  the  length  of  each  tuple. 
Appendix  IE  is  another  list  of  relations  but  this  one  shows  the  attri¬ 
butes  which  comprise  each  relation  with  the  key  attributes  for  each, 
denoted  with  an  Appendix  IF  provides  a  detailed  breakdown  of  all 
the  attributes  by  listing  the  size  of  each  attribute  a  description,  an 
example  of  how  it  is  to  be  used,  a  list  of  the  relations  which  incor¬ 
porate  it,  and  any  synonyms  it  might  have.  Appendix  10  is  a  list  of  the 
logical  views  of  the  database.  These  views  also  reflect  each  director¬ 
ates  data  requirements  as  presented  in  the  interviews.  Appendix  LH 
gives,  for  each  relation,  the  estimated  total  number  of  records  stored  in 
memory  at  the  end  of  the  first  years  operation  of  CADIS.  Also  given  are 
the  factors  going  into  each  estimate  and  the  major  source  of  those  fac¬ 
tors. 


Database  Size  Estimation 

The  estimated  size  of  the  database  is  28,550,000  bytes  of  data. 
This  figure  represents  the  total  amount  of  memory  required  for  one  full 
year  of  operation  (several  relations  maintain  four  quarters  worth  of 
data).  No  student  history,  other  than  a  short  educational  history  for 
1000  students,  or  registrar  data  has  been  included  in  the  estimate. 

This  estimate  was  derived  by  taking  the  size  of  each  relation,  as 
determined  by  the  sum  of  the  lengths  of  its  attributes,  and  multiplying 
it  by  the  estimated  number  of  tuples  for  that  relation.  Figures  tor  the 
lengths  of  each  relation  were  derived  by  actual  counts,  estimates  tro.n 
faculty  or  staff  members  or  by  the  authors'  best  estimation  and  can  be 
found  In  appendix  III. 
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For  ease  of  computation  it  was  assumed  that  all  data  would  be  stored 
in  character  format  and  that  one  character  would  occupy  one  byte  of 
memory.  This  size  estimate  does  not  include  the  core  memory  required  for 
the  DBMS  itself  to  function. 

2^.2^.  _7»  Unde  fined/ Incomplete  Data  Requirements 

Appendix  I  encompasses  the  entirety  of  the  AFIT  information/data 
requirements  identified  during  the  interviews.  Implementation  of  the 
database  as  designed  will  alleviate  approximately  90-95%  of  the  AFIT 
information  problems  identified.  The  data  considered  as  "missing"  from 
the  design  was  compiled  from  two  entirely  different  sources,  the 
worksheet  and  comments  by  each  interviewee,  and  represents  those  items 
which  could  not  be  Included  into  the  design  for  the  reasons  listed  below. 

The  reasons  this  data  was  not  included  is  because  it  was:  a)  submit¬ 
ted  too  late  in  the  design  process,  b)  stated  in  a  format  which  was  much 
too  general  in  nature,  or  c)  contained  various  elements  were  very 
specific  to  a  single  area  and  not  desired  by  anyone  else. 

The  largest  single  Influencing  factor  concerning  the  information  not 
included  was  that  of  time.  Each  interviewee  was  contacted  in  sufficient 
time  to  respond  with  their  requirements  and  have  them  included  (some  were 
given  much  more  than  were  others).  However,  there  were  those  who  were 
unable  to  identify  their  total  requirements  quickly  enough.  Therefore, 
only  that  portion  received  early  enough  was  able  to  be  included,  In  gen¬ 
eral,  the  data  which  falls  into  this  category  is  not  to  be  considered 
"essential"  and  the  current  structure  will  fulfill  the  vast  majority  of 


PACE  27 


1 


Che  requirements. 

Each  person  interviewed  was  asked  to  be  as  specific  as  possible  as 
to  what  data  was  required  for  their  area.  Everyone  was  asked  to  use  the 
worksheet  to  mark  their  input  and  any  item  which  was  not  SPECIFICALLY 
identified  as  UNDESIRABLE  was  included.  In  spite  of  this,  some  people 
simply  Identified  their  "general  ADP/inf ormation  requirements"  in  a  very 
non  specific  manner.  For  instance,  the  most  common  area  identified  this 
way  wa6  "budget  data".  Because  of  the  nature  of  this  thesis,  there  was 
insufficient  time  to  perform  the  in-depth  system  analysis  required  to 
translate  this  type  of  request  into  actual  database  requirements.  AFIT 
will  have  to  supply  the  qualified  personnel  to  work  with  these  areas  and 
perform  this  lengthy  analysis  at  a  later  date. 

Finally,  some  areas  supplied  data  which  was  rather  narrow  in  use  and 
was  oriented  to  a  small  subset  of  their  directorate  (mainly  AF1T/EN  and 
LS  directorates).  This  type  of  data  was  excluded  because  it  was  felt 
that  because  it  was  not  actually  "common",  it  should  be  reviewed  for 
desirability  and  applicability  across  the  directorate  prior  to  inclusion. 

The  data  listed  in  appendix  IJ  is  reproduced  exactly  as  it  was 
received  from  the  worksheets. 


2.2.8.  Recommendations  for  Data  Use  and  Data  Structures 

Because  of  the  uncertainty  as  to  which  DBMS  will  eventually  support 
CADIS,  the  structure  and  use  of  several  attributes  within  the  database 
may  have  to  be  modified  from  their  format  as  presented  in  appendix  I. 
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The  primary  factor  leading  to  this  decision  will  be  the  sophistication  or 
limitations  of  the  DBMS  and  its  query  facility.  As  an  example,  the 
attribute  'Course1  may  need  to  be  broken  into  four  smaller  attributes 
Course_Type,  Course_Level,  Cour se_Number ,  and  Section  (e.g.  EE686A  »  EE- 
6-86-A).  If  the  components  cannot  be  accessed  directly,  such  elementary 
questions  as  "how  many  graduate  courses  (Course_Level  >  500)  are  offered** 
or  "what  courses  have  multiple  sections  being  taught  (Section  is  non¬ 
blank)"  cannot  be  answered  because  the  DBMS  might  view  the  attribute  as 
one  contiguous,  unbreakable  character  string.  If,  however,  the  query 
facility  has  a  string  search  capability  (e.g.  select  data  when  the  third 
character  >  5)  this  kind  of  breakdown  would  not  be  necessary.  The  abil¬ 
ity  to  perform  these  operations  will  vary  with  the  DBMS  and  must  be 
closely  studied  prior  to  implementation. 

The  attributes  which  may  require  further  breakdown  are: 

(1)  Course;  into  Course_Department ,  Course_Level ,  Course_No,  and  Sec¬ 
tion. 

(2)  Office;  into  Directorate  and  Division  (ENA  -  EN-A). 

(3)  Extra_Dutles;  into  some  more  meaningful  breakdown  as  determined  by 
AFIT/DA. 

(4)  Section;  into  Section_Type ,  Sect ion_Year ,  and  Section_Month  (CCS820 
-  GCS-82-D). 

(5)  Name;  into  Last_Name,  First_name_Ml  (This  holds  for  all  attributes 
which  contain  a  name  like  attribute). 
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(6)  Dace;  into  Day,  Month  and  Year. 

(7)  Degree_Code;  into  Degree_Level  and  Degree  (e.g.  MS-EE). 

Two  additional  pieces  of  data  will  have  to  be  examined  further  and 
decided  upon  prior  to  the  establishment  of  the  database.  These  are  the 
establishment  of  identification  numbers  for  foreign  students,  similar  to 
SSAN,  and  how  much  of  the  GRE  and  GMAT  scores  are  to  be  stored.  Ini¬ 
tially,  the  database  has  been  designed  to  carry  total  scores  only,  but  if 
the  demand  is  great  enough  for  the  component  scores,  it  is  recommended 
that  a  set  of  indicators  and  relations  be  established  similar  to  those  in 
the  registrars  relations  (appendix  ID  &  IE,  relations  78  -  80). 

It  was  a  general  rule  to  make  all  codes  :.n  meaningful  as  possible 
when  viewed  by  themselves.  Specifically  avoided  was  the  unclear  or  ambi¬ 
guous  use  of  single  letters  or  digits.  By  so  doing,  a  large  amount  of 
confusion  will  be  eliminated  when  data  is  viewed  or  used  apart  from  the 
full  descriptions  or  long  versions  of  the  attributes.  For  example,  a 
tuple  such  as  "John  Jones,  M,  5135B,  P,  SE"  tells  its  user  that  John 
Jones  is  married,  is  a  5135B  computer  programmer,  is  a  pilot,  is  married 
and  has  a  secret  security  clearance  much  clearer  than  does  a  tuple  such 
as  "John  Jones,  1,  5135B,  A,  1,  2". 

Whenever  possible  a  code  was  indexed  into  another  relation  which 
contains  its  full  description  or  title.  This  practice  makes  adding  or 
deleting  codes  from  the  database  easier  and  also  facilitates  edit  check¬ 
ing  and  validation.  There  are  some  codes  used  in  appendix  IF  which  do  not 
uBe  such  a  structure.  In  these  cases  the  codes  have  a  very  limited  range 
of  possible  values,  say  two  to  four.  If  a  DBMS  is  chosen  with  the  proper 


capabilities,  these  values  can  be  defined  in  the  database  definition 
mechanism  as  parameters,  and  the  DBMS  software  will  perform  edit  checking 
automatically.  When  available,  this  feature  is  easy  to  use  and  change 
and  frees  application  programs  from  time  consuming  and  lengthy  validity 
checks  which  must  be  performed  in  order  to  guarantee  the  Integrity  of  the 
data. 

All  attributes  are  defined  as  characters  for  ease  of  computation  and 
there  are  some  distinct  advantages  to  leaving  the  database  this  way. 
Depending  on  how  much  numerical  manipulation  is  performed,  the  savings  in 
memory  and  processor  time  might  outweigh  the  computational  speed  gained 
by  storing  numeric  values  versus  storing  attributes  such  as  No_Students 
as  characters  and  letting  the  DBMS  convert  the  values  whenever  computa¬ 
tion  is  desired.  This  is  a  decision  which  must  be  left  to  those  who  will 
Implement  this  design. 

_2._2.9_.  Recommended  CADIS  Management  Structure 

Volumes  and  volumes  of  material  have  been  published  over  the  years 
on  the  technical  aspects  of  DBMSs.  On  the  other  hand  comparatively  lit¬ 
tle  has  been  written  on  the  subject  of  management  techniques,  practices 
or  methods  associated  with  implementing  and  running  such  systems. 
According  to  what  literature  is  available  it  seems  to  fall  upon  the  indi¬ 
vidual  organization  to  review  their  situation  and  develop  their  own 
methods.  There  is  however,  a  set  of  sound,  concrete  reasons  for  going  to 
the  trouble  of  developing  an  adequate  management  structure.  "The  data¬ 
base  will  have  a  major  impact  on  the  enterprise,  not  only  in  terms  of 
benefits  but  in  terms  of  problems.  Its  fundamental  aspect  of  the  sharing 
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of  data  among  usera  and  of  greater  central  control  of  data  are  just  the 
type  of  changes  that  can  have  severe  political  repercussions  within  an 
organization.*1  (REF  16t  p  5-1) 

In  order  for  an  integrated  database  to  be  effective,  such  things  as 
setting  standard  definitions,  formats  and  usages  for  all  data  elements 
plus  the  associated  monitoring  and  enforcement  of  these  standards  is 
essential.  This  will  insure  the  existence  of  accurate  and  consistent 
data  for  all  users  who  will  quickly  come  to  depend  heavily  upon  the  data¬ 
base  for  meeting  their  mission  requirements. 

"Resentment  to  the  disciplines  Imposed  by  the  database  can  often 
arise;  some  departments  might  Insist  on  applying  their  own  standards  [or 
methods  of  database  management].  Such  difficulties  can  be  overcome,  but 
only  if  the  continued  and  dedicated  support  [and  guidance]  of  senior 
management  is  assured."  (REF  16,  p  5-1) 

The  solution  most  often  adopted,  and  recommended  by  industry  prac¬ 
tice  and  writing,  is  to  establish  a  specialized  area  of  the  organization 
whose  primary  consideration  is  the  administration  and  control  of  the 
database  and  its  operation.  This  'Database  Administrator  (DBA)'  must  be 
"familiar  with  the  use  and  nature  of  all  the  data,  ...be  vitally  con¬ 
cerned  with  the  performance  of  the  system  and... be  able  to  negotiate  with 
and  resolve  conflicts  between  user  departments.. (REF  16,  p  5-24)  In 
short  this  position  should  be  filled  with  someone  who  is  totally  com¬ 
petent  in  all  the  technical  aspects  of  a  DBMS  plus  have  intimate 
knowledge  of  the  organization  and  its  operation.  But  most  importantly, 
he  must  be  someone  who  has  the  authority  to  make  and  enforce  decisions 


Involving  the  database 


2.2.10.  AFIT  Management  Features  &  Problems 

In  most  respects  AFIT  is  no  different  than  other  civilian  and 
government  organizations.  There  is  a  shortage  of  qualified  personnel  and 
those  who  are  available  do  not  have  the  necessary  database  experience  to 
Implement  and  control  such  a  project.  For  the  most  part  AFIT  will  cope 
with  these  universal  problems  just  like  everyone  else  and  rely  on  the 
available  pool  of  expertise  from  other  areas  and  accomplish  the  project 
anyhow.  Additionally,  there  are  some  problems  which  while  they  are  not 
unique  to  AFIT,  present  some  real  obstacles. 

There  is  a  decided  lack  of  practical  experience  with  the  design, 
implementation  and  management  of  DBMSs.  This,  coupled  with  the  fact  that 
this  would  be  a  ''new  start”  project  could  combine  iuto  a  deadly  eu.ibina- 
tion  if  the  proper  precautions  are  not  taken  immediately. 

AFIT  has  a  diverse  community  of  users  which  view  the  concepts  of 
database  systems  and  data  automation  from  three  extremely  differing  per¬ 
spectives;  that  of  academic,  administration  and  real  world.  The  result 
is  a  situation  not  too  uncommon,  that  is,  differing  opinions  on  the  con¬ 
trol  of  data  and  the  methods  and  procedures  for  implementing  a  central¬ 
ized  database. 

2.2.11.  CADIS  Management  Recommendations 

The  optimum  solution  for  the  administration  of  CADIS  appears  to  be 
one  with  two  components.  First,  "the  solution  most  frequently  offered 
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for  this  type  of  situation  is  placing  the  administrative  responsibilities 
in  a  staff  position,  reporting  directly  to  the  highest  manager  responsi¬ 
ble  for  data  processing  in  the  organization."  (REF  2,  p  6)  Secondly, 
"the  database  administrator  functions  should  be  a  team  rather  than  a  sin¬ 
gle  manager".  (REF  16,  p  5-24) 

The  Database  Administrator  (DBA)  position  is  a  very  demanding  one. 
he  is  faced  with  deciding  such  things  as  "resolving  conflicts  of  owner¬ 
ship  if  several  departments  wish  to  amend  or  retrieve  the  same 
data. . .negotiating  with  users  to  establish  who  has  the  right  to  access  or 
change  data  items. • .providing  recovery  facilities  and  establishing  pre¬ 
cautions  for  applications  in  the  event  of  a  breakdown. . .establishing  data 
entry,  edit  and  validation  standards,  and  maintaining  the  data  diction¬ 
ary."  (REF  16,  p  5-26,27)  "Por  the  data  administrator  to  have  suffi¬ 
cient  authority  to  be  accepted  by  user  departments,  to  reconcile  their 
conflicting  requirements  for  data,  and  to  be  able  to  enforce  standards, 
the  position  must  be  relatively  senior  within  ti.c  enterprise."  (REF  16,  p 
5-26) 

Based  on  the  above  comments  it  is  recommended  that  AF1T  initiate  two 
separate  levels  or  areas  of  administration  for  CADIS.  The  first,  that  of 
the  Database  Administrator  (DBA),  should  be  a  senior  member  of  the  staff 
with  sufficient  authority  and  knowledge  of  the  organization  to  shepherd 
the  database,  with  all  of  its  growing  pains,  through  to  full  adulthood. 

To  aid  the  DBA,  and  as  part  of  the  first  level  of  CADIS  administra¬ 
tion,  each  directorate  should  have  a  single  representative  or  Data 
Administrator  (DA)  which  would  represent  the  views  and  needs  of  their 


respective  functional  areas.  All  new  requirements  and  problems  would 
first  be  reviewed  by  a  DA  for  clarity,  consistency  and  practicality.  He 
should  also  be  able  to  answer  any  question  about  current  data  usage  and 
meaning  as  well  as  act  as  the  focal  point  for  any  problems  or  changes  to 
the  database  originating  from  or  directed  to  his  directorate.  Once  dis¬ 
cussed  at  this  level,  anything  of  Interest  to  the  community  of  users, 
valid  changes  to  the  structure  of  the  database  or  disputes  should  be 
taken  to  the  DBA  for  review  and  action.  The  DBA  would  check  them  for 
validity,  then  for  consistency  against  prescribed  rules  and  standards  and 
act  accordingly. 

Once  the  DBA  has  approved  the  changes  or  resolved  any  problems  with 
the  recommendations,  they  would  Chen  be  passed  on  to  the  other  component 
of  CADIS  management,  the  Database  Manager  (DBM).  This  person  or  group 
would  act  only  on  the  direction  of  the  DBA  and  should  not  be  a  member  of 
the  staff  but  someone  with  a  more  technical  orientation  toward  DBMSs. 
This  must  be  the  case  because  he  is  the  one  who  will  monitor  and  be  in 
charge  of  the  DBMS  software,  make  any  changes  to  the  structure  of  the 
database  as  dictated  by  the  DBA,  as  well  as  being  the  interface  to  the 
vendor  and  acting  as  the  ultimate  in-house  technical  representative.  The 
DBM  should  not  be  involved  in  data  oriented  problems,  but  only  In  the 
efficient  operation  of  the  DBMS  itself  on  who  ever  computer  system  it  is 
lnstal led . 

It  is  very  likely  that  the  CCB  could  suffice  for  the  first  level  of 
the  previously  mentioned  structure,  with  the  directorate  representatives, 
or  their  appointees,  acting  as  the  DAs .  The  second  level  of  administra¬ 
tion  should  be  performed  by  AFIT/ACD.  They  could  supply  one  or  more 
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people  to  act  as  the  DBM  since  the  type  of  the  technical  expertise 
desired  resides  with  them.  The  job  of  DBM  would  very  likely  be  a  full 
time  assignment  during  the  infancy  of  CADIS  but  could  become  a  background 
duty  once  it  is  operational. 

In  general,  each  functional  area  needs  to  be  responsible  for  their 
own  data,  AFIT/ACD  should  be  in  charge  of  the  computer  and  the  DBMS 
software  and  serve  as  technical  representative  for  their  combined  use. 

For  this  to  become  a  viable  management  framework,  the  general  level 
of  education  in  regard  to  DBMSs  has  to  first  be  Increased.  AFIT  should 
immediately  begin  to  send  people  to  the  database  courses  (basic  and 
advanced)  offered  within  the  School  of  Engineering.  They  also  need  to 
talk  to  vendors  and  visit  other  AF  installations  which  have  experience  in 
database  systems.  Additionally,  the  heads  of  each  of  the  directorates 
should  at  least  attend  the  database  short  course  available  periodically 
at  AFIT/EN.  These  suggestions  are  wholeheartedly  recommended  because  the 
uniqueness  and  nuances  of  DBMSs  dictate  a  need  to  become  familiar  with 
the  theory  and  practices  of  a  database  operation.  Without  this  basic 
understanding  of  the  functions  and  capabilities  of  a  DBMS,  by  all  those 
Involved,  it  is  nearly  impossible  to  successfully  implement  CADIS  and 
have  it  as  useful  as  it  could  be.  Such  education  should  be  above  and 
beyond  the  normal  training  classes  which  will  be  offered  for  the  DBMS  by 
the  vendor  once  it  is  installed.  The  DBA  and  the  DBM  should  be  the  first 
to  seek  this  type  of  knowledge,  and  as  soon  as  possible,  followed  closely 
by  the  DAs  and  their  users.  One  can  never  hope  to  build  and  operate  that 
which  he  does  not  understand  and  trust. 
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2.2.12.  Database  Implementation  Recommendations 

In  order  to  Implement  a  database  and  bring  the  users  'on-line'  with 
the  minimum  amount  of  mayhem  and  confusion,  plans  must  be  drawn  up  for 
the  implementation  well  in  advance  of  the  actual  event.  The  purpose  of 
this  section  Is  to  suggest  one  scheme  which  would  ease  the  'labor  pains'. 
A  basic  premise  for  any  implementation  plan  is  to  try  and  achieve  the 
most  results  with  the  least  expenditure  of  and  resources. 

First,  a  Database  Implementation  Team  (D^ri),  composed  of  at  least 
the  DBA  and  DBM,  should  evaluate  the  user  community  in  order  to  determine 
any  highly  critical  areas  which  were  not  known  at  the  time  of  the 
requirements  analysis  and  superimpose  them  upon  the  following  general 
plan  discussed  below.  Additionally,  AFIT/ACD  will  have  to  supply  two  or 
three  people  on  a  full  time  basis  for  at  least  a  year  in  order  to  Imple¬ 
ment  CADIS. 

2.2.13.  Ceneral  CADIS  Implementation 

The  OBIT  should  not  under  any  circumstances  attempt  to  load  all  the 
relations  prior  to  allowing  the  users  access  to  the  database.  This  is 
just  common  sense,  good  top-down  implementation  practice  and  will  prevent 
massive  confusion  and  eliminate  wasted  human  and  computer  time  spent 
resolving  problems.  If  all  the  relations  are  loaded  at  once,  this  would 
cause  the  majority  of  the  users,  who  could  operate  with  a  subset  of  the 
data,  to  wait  an  unnecessarily  long  time  before  becoming  operational. 
Also,  by  giving  the  data  to  the  users  in  usable  segments,  they  will  have 
the  opportunity  to  fully  evaluate  and  test  the  features  of  the  system  and 
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find  any  errors  In  Che  daCa  or  its  structure  easier  than  if  all  of  their 
data  was  present.  Additionally,  when  a  new  system  is  presented,  "com¬ 
plete"  or  "fully  capable",  the  users  tend  not  to  learn  it  thoroughly  nor 
learn  how  to  use  Its  full  capabilities,  but  learn  just  enough  to  get  by. 

The  Inclusion  of  the  registrar  should  be  left  aside  at  this  time 
because  of  their  current  automation  effort  and  the  many  complexities  and 
controversies  associated  with  their  type  of  data.  But  if,  at  some  later 
date  when  the  all  of  CADIS  has  been  implemented  and  exercised,  it  is 
deemed  desirable,  then  and  only  then  should  AFIT/KRs  inclusion  be  con¬ 
sidered.  What  should  be  Implemented  at  this  time  is  the  subset  of  the 
registrars  data  which  was  requested  by  the  remainder  of  AF1T.  By  so 
doing  it  la  assured  that  CADIS  will  be  truly  useful  to  its  users.  Also, 
the  mistakes  and  hardships  which  surround  an  organization  trying  to 
operate  with  its  essential  data  needlessly  spread  among  multiple  data 
systems  are  eliminated. 

Finally,  it  would  be  easier  all  around,  plus  create  experience  with 
the  new  system  if  each  user  was  generally  responsible  for  loading  their 
own  data.  No  one  knows  the  data  like  the  individual  departmentmental 
users  do,  and  with  the  DBA  and  DBM  assisting  by  supplying  routines  and 
advice,  Implementation  would  proceed  much  faster. 

2 .2 . 1A .  CADIS  Implementation  Plan 

The  intent  of  this  plan  is  to  install  or  expand  (load  and  verify) 
the  database  in  sections  which  will  do  the  most  good  for  the  most  people. 
The  steps  are  not  necessarily  mutually  exclusive  and  several  steps  may  be 
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in  various  stages  of  execution  at  any  given  time.  More  capable  users  may 
be  able  to  get  their  data  loaded  quicker  than  others  and  no  attempt 
should  be  made  to  slow  them  down  if  they  can  be  administered  adequately. 

The  following  steps  constitute  the  CADIS  Implementation  Plan: 

(1)  The  DBA  and  DAs  should  mutually  establish  the  data  standards  and 
codes  which  will  be  used  throughout  the  system. 

(2)  Define  the  entire  database  structure  in  the  computer  at  one  time. 
This  would  consist  of  those  relations  and  attributes,  along  with 
their  ruleB,  as  defined  in  appendix  I  or  by  the  DBA.  By  doing  this 
first,  modification  of  the  basic  structure  can  be  kept  at  a  minimum 
and  nothing  extra  needa  to  be  done  when  a  user  is  ready  to  load  a 
relation. 

(3)  Initially  load  those  relations  which  comprise  the  'core'  of  CADIS 
under  the  supervision  of  the  DBA.  This  will  allow  AFIT/EN,  LS,  DE, 
PA,  ED,  and  Cl  to  go  into  limited  operation  very  quickly  and  allow 
them  to  start  testing  out  the  structure  and  their  data.  This  'core' 
is  comprised  of  the  STUDENT  and  STAFF  relations  plus  those  relations 
which  allow  them  to  function  properly.  These  core  relations 
include:  OFFICES,  ACADEMIC JTITLES ;  STUDENTS,  STAFF  ED_CODES,  SEC¬ 
TION,  FOREIGN_STUDENT_DATA,  CURRENT_THESES,  CI_DATA;  DEJOATA; 
RESIDENTJDATA;  MAJCOMS,  SPOUSES,  LOCATIONS  (only  the  subset  large 
enough  to  allow  minimum  operations),  and  AFIT  CALENDAR. 
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(4)  Once  the  'core'  has  been  Installed  and  verified  for  completeness, 
the  users  can  begin  to  load  the  special  purpose  relations  which  per¬ 
tain  to  their  particular  operation.  These  relations  include: 
BOXES,  LOCKERS,  EDJilST,  PAST_COURSES,  ED_PLANS,  EXTRAJDUTIES, 
EXT  RA_DUTY_ROS TE R ,  DUTY_OFFICER,  PROMOTIONS  TATS,  QUOTAS,  PCE_DATA, 
DECREE_S OUGHT,  DEGREES  and  all  the  faculty  related  relations. 

(5)  Complete  the  loading  of  the  LOCATIONS  relation  with  the  remaining 
data  required  by  AFIT/C1  and  others. 

(6)  Finish  installing  the  relations  which  pertain  to  AFIT/CI.  These 
relations  are:  CURRENT_C  I_PROGRAMS ,  CI_PROCRAMS,  INST_PAYMENTS, 
1NST_P0CS,  SCHOOL/EWI_DATA ,  MMEP_DATA,  MED_B0ARD_CERTIFICAT10N, 
MED_TOURS  and  MED_PROG. 

(7)  Load  the  course,  book  and  room  data.  These  relations  consist  of: 
AFIT_COURSES,  PREREQ,  COURSEJJOOKS ,  BOOKS  and  ROOMS. 

(8)  Load  the  course  scheduling  and  other  data  from  the  registrars  sys¬ 
tem.  This  Includes  the  following  relations:  COURSE_TIMES , 

STUD_SCHED,  SI!ORT_COURSES,  FAC_COURSES,  SHORT_STUDENTS. 

(9)  Load  the  leftover  relations  as  the  data  becomes  available. 

(10)  Begin  loading  the  THESES  and  STUDENT_HIST  relations  as  appropriate. 

If  this  type  of  approach  is  followed,  an  effective  management  struc¬ 
ture  is  instituted  and  the  people  are  properly  educated,  CADIS  can  be  at 
least  85%  operational  in  about  one  year.  Impacting  on  this  estimate  are 
the  decisions  as  to  the  DBMS,  the  hardware  and  the  speed  with  which  the 


data  is  gathered  and  prepared  for  entry  into  the  database.  Preparation 
could  begin  immediately  after  the  DBMS  is  decided  upon  by  storing  it  on 
the  machine  to  be  used  via  tapes  or  a  text  editor.  This  data  can  then  be 
easily  prepared  for  final  loading  at  a  later  -ate. 

2.2.15.  Interfaces  to  CADIS 

For  purposes  of  this  section,  the  term  "interface”  will  mean  any 
data  which  one  data  system  may  provide  or  receive  from  another  data  sys¬ 
tem.  There  is  no  Intention  to  imply  a  method  or  media  for  accomplishing 
the  actual  transfer. 

The  following  are  recommended  Interfaces  to  CADIS: 

(1)  Let  the  AF  Standard  Personnel  System  periodically  supply  data  on  the 
AF  students  and  staff  at  AFIT.  One  problem  identified  by  AF1T/DP 
was  rhat  the  data  maintained  by  the  schools  on  their  students  is 
almost  always  more  current  than  that  maintained  by  themselves  and 
the  AF  personnel  system.  By  having  AFIT/DP  supply  some  attributes 
and  have  them  updated  only  via  the  interface,  the  only  way  a  partic¬ 
ular  students  record  could  be  changed  is  by  going  through  AFIT/DP 
and  modifying  their  permanent  record.  Changes  in  the  data  would 
then  show  up  in  the  database  at  the  next  update.  The  primary  reason 
for  utilizing  this  interface  would  be  to  assure  AFIT  of  the  most 
current,  official  data  on  on  a  student.  AFIT  could  therefore 
prevent  their  student  data  from  becoming  substantially  different 
from  his  permanent  record  and  visa  versa.  (NOTE:  AFIT/DE  currently 
receives  a  periodic  data  tape  from  Randolph  AFB.) 
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(2)  Allow  Che  registrar  Co  supply  data  Co  CADIS  for  Che  following  rela¬ 
tions:  COlfRSE_TIMES,  AFIT_COURSES,  STUD_SC11EU,  FACjCOURSES, 

PCE_DATA,  SHORT_COURSES ,  SHORT_STUDENTS  along  with  the  degree  which 
a  student  is  seeking*  While  this  daca  probably  does  not  exist  in  a 
directly  transferable  format,  enough  can  be  supplied  and  converted 
to  guarantee  consistency  across  AFIT. 

(3)  Let  CADIS  supply  the  registrar  with  the  student  grades  at  the  end  of 
each  term.  Instead  of  faculty  members  filling  out  grade  sheets  and 
passing  them  to  AFIT/RR.  Crades  for  students  would  simply  be 
entered  into  CADIS  once  and  the  whole  school  could  transferred  in 
one  easy  step.  Also,  departments  and  advisors  would  have  the  past 
grades  which  they  requested  for  each  of  their  students. 

(4)  When  the  students  schedule  is  received  from  the  registrar  (via 
interface  number  two)  and  entered  into  CADIS,  a  check  could  be  made 
against  his  educational  plan  (ED_PLANS  relation)  and  any  deviations 
from  that  plan  could  be  flagged  for  the  faculty  advisor. 

(5)  When  the  COURSE_TIMES  data  is  supplied  to  CADIS,  that  same  data 
could  be  used  to  update  the  ROOM_SCHED  relation  for  the  current 
quarter. 

2.3.  DATABASE  STRUCTURE  and  DESIGN 

"The  real  benefits  of  a  database  can  be  realized  only  if  It  models 
the  operation  of  the  enterprise.  The  database  must  represent  entitles 
and  their  relationships .. .The  model  must  not  be  dependent  on  such  issues 
as  hardware,  operating  systems  or  host  languages. . [otherwise]  the 
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resulting  design  will  not  model  reality."  (REF  16,  p  5-13) 

"Relations  can  be  used  to  model  the  "real  world"  in  several  ways; 
for  example,  each  tuple  of  a  relation  could  represent  an  entity  and  Its 
attributes  or  a  relationship  between  entitles,  However,  in  many  cases, 
the  known  facts  about  the  real  world  imply  that  not  every  finite  set  of 
tuples  could  be  the  current  value  of  some  relation,  even  if  the  tuples 
were  of  the  right  arlty  and  had  components  chosen  from  the  right 
domains."  (REF  17,  p  167-168) 

These  real  world  implications,  which  limit  the  tuples  that  can  be 
values  for  a  given  relationship,  point  out  the  existence  of  certain  res¬ 
trictions  on  relations.  Jeffrey  Ullman  distinguishes  between  two  kinds 
of  restrictions  on  relations.  The  first  are  those  typeB  of  restrictions 
that  depend  on  the  semantics  of  domain  elements.  This  class  of  restric¬ 
tions  tells  little  or  nothing  about  the  design  of  a  database  schema. 
Examples  of  this  first  type  of  restriction  are  that  there  is  no  (offi¬ 
cial)  ACADEMIC_TITLE  of  "Tyrant",  nor  can  anyone's  LOCAL_ADDKESS  be 
"Rural  Route  1,  Mars".  (REF  17,  p  168) 

The  second  kind  of  relation  restrictions  are  those  that  depend  only 
on  the  equality  or  inequality  of  values  of  attributes  shared  by  more  than 
one  tuple.  This  type  of  constraint  does  not  depend  on  what  value  a  tuple 
has  in  any  given  component,  but  only  on  whether  two  tuples  agree  in  cer¬ 
tain  components.  The  most  Important  of  these  constraints  are  called 
functional  dependencies,  and  are  a  form  of  value-oblivious  constraint. 
It  is  the  value-oblivious  constraints  that  have  the  greatest  impact  on 
the  design  of  database  schemes.  (REF  17,  p  168) 


"Let  R(A1 ,A2 , . . . ,An)  be  a  relation  scheme,  and  let  X  and  Y  be  sub¬ 
sets  of  (Al,A2, .. . ,An) .  We  say  X->Y,  read  "X  functionally  determines  Y" 
or  “Y  functionally  depends  on  X"  if  whatever  relation  r  is  the  current 
value  for  R,  it  is  not  possible  that  r  has  two  tuples  that  agree  in  the 
components  for  attributes  in  set  Y".  (REF  17,  p  168) 

One  natural  and  frequently  occurring  example  of  a  functional  depen¬ 
dency  is  that  of  a  key  and  an  entity  set.  For  example,  if  R  represents 
an  entity  set,  and  Al,...,An  are  the  attributes  of  that  entity  set,  and 
if  X  is  a  set  of  attributes  that  forms  a  key  for  the  entity  set,  then  one 
can  assert  X->Y  for  any  subset  Y  of  attributes.  This  follows  because  the 
tuples  of  r  represent  entities,  and  entities  are  identified  by  the  value 
of  attributes  in  the  key.  Therefore,  two  tuples  that  agreed  on  the 
attributes  in  X  would  have  to  represent  the  same  entity  and  therefore  be 
the  same  tuple.  (REP  17,  p  168) 

It  is  vitally  important  to  realize  that  the  declaration  of  a  func¬ 
tional  dependency  in  a  database  is  a  decision  that  can  only  be  made  by 
the  designer.  The  advantage  of  such  a  declaration  is  that  the  database 
system  will  then  enforce  an  integrity  constraint  for  the  user,  and  there 
could  even  be  a  more  efficient  implementation  of  the  relation  possible 
because  the  functional  dependency  is  asserted  to  hold.  However,  there  is 
a  price  to  be  paid,  in  chat  the  storage  of  certain  information  becomes 
impossible.  For  example,  if  one  decides  NAME  functionally  determines 
HPHONE,  then  under  no  circumstance  is  it  possible  to  store  two  home  phone 
numbers  for  one  person  in  the  database.  (REF  17,  P  16b-Ib9) 
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(NOTE:  In  Che  foregoing  and  following  discussion  an  important 
assumption  is  ChaC  a  key  X  for  R  is  by  definition  the  minimal  set  of 
attributes  that  uniquely  determines  a  tuple  of  R.) 

Normal  Forms  For  Relation  Schemes 

A  number  of  different  properties,  or  "normal  forms",  for  relation 
schemes  with  dependencies  have  been  defined.  One  of  the  most  significant 
of  these  is  called  "third  normal  form"  (3NF).  This  normal  form  guaran¬ 
tees  that  most  problems  of  data  redundancy  and  most  insertion  and  dele¬ 
tion  anomalies  do  not  occur.  (REF  17,  p  187) 

To  define  these  terms,  it  is  first  necessary  to  define  a  "prime" 
attribute.  An  attribute  A  in  relation  scheme  R  is  a  prime  attribute  if  A 
is  a  member  of  any  possible  key  for  R.  If  A  is  not  a  member  of  any  key, 
then  it  is  nonprime  .  (REF  17,  P  187) 

.JJ  .2^.  Third  Normal  Form 

A  formal  definition  of  third  normal  form  is:  "A  relation  scheme  R  is 
in  third  normal  form  if  and  only  if  there  does  not  exist  a  key  X  for  R,  a 
sec  of  attributes  Y  £  R,  and  a  nonprime  attribute  A  of  R  not  in  X  or  Y, 
such  that 

1.  X->Y  holds  in  R, 

2.  Y->A  holds  in  R,  but 

3.  Y->X  does  not  hold  in  R. 

If  Y  is  a  subset  of  X,  and  therefore  by  Y  is  a  proper  subset  of 

X,  then  R  is  said  to  have  a  partial  dependency.  If  Y  is  not  a  subset  of 
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X,  then  R  has  a  transitive  dependency.  If  R  satisfies  the  above  condi¬ 
tion  whenever  Y  C  X,  but  not  necessarily  otherwise,  then  R  is  said  to  be 
in  second  normal  form.”  (REF  17,  p  187) 

2^_3 . 3..  Summary  of  Design  Approach 

It  was  decided  to  adopt  a  relational  approach  to  the  AF1T  database 
design  for  several  reasons. 

1.  The  power  of  relations  to  model  the  real  world,  both  entitles 
and  their  relationships. 

2.  The  fact  that  the  relational  model  forces  the  analyst  to  note 
the  dependencies  of  each  relation,  and  in  arriving  at  the  optimal 
third  normal  form,  to  eliminate  many  redundant  items  and  to  also 
eliminate  many  potential  update  anomalies. 

(REF  13,  P  5-13) 

3.  The  flexibility  and  easy  expandability  of  the  relational  approach. 

4.  The  simplicity  of  the  view  of  the  database  that  users  see  is 
that  of  two  dimensional  or  flat  files. 


All  relations  in  the  AF1T  database  design  (Appendix  1)  are  in  at 
least  3NF.  This  was  proven  by  an  exhaustive  inspection,  i.e.,  by  taking 
all  functional  dependencies  for  each  relation  (Appendix  1,1)  and  evaluat¬ 
ing  them  against  the  definition  of  3NF.  Any  relations  which  failed  to 
satisfy  this  formal  definition  were  redesigned.  This  process  was 
repeated  Iteratively  until  all  relations  were  normalized  to  3NK. 
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III  EVALUATION  OP  VARIOUS  DBMSs 

2*  CENERAL  OUTLOOK,  DESIRES  and  ASSUMPTIONS 

Having  already  realized  the  need  for  improvements  to  the  information 
handling  procedures  within  AFIT  and  the  fact  that  a  DBMS  is  the  proper 
and  correct  solution,  it  is  now  essential  that  the  optimal  DBMS(s)  which 
can  effectively  accomplish  this  task,  be  identified.  The  general  purpose 
of  this  section  is  to  examine  as  many  commercially  available  DBMSs 
(including  those  already  procured  by  AFIT  ano  ti.Jae  available  through  the 
federal  government),  evaluate  their  features  and  characteristics  and 
determine  which  one(s)  will  best  support  an  integrated  AFIT  database  as 
identified  in  the  previous  chapters. 

The  basic  underlying  assumption  is  the  fact  that  the  appropriate 
DBMS  is  currently  available.  There  is  no  desire  nor  are  there  sufficient 
resources  to  invest  in  the  construction  of  a  system  specifically  tailored 
to  AFIT.  In  reality  the  needs  and  desires  of  the  personnel  contacted  are 
not  beyond  current  technology  and  not  substantially  different  from  other 
institutions  and  organizations. 

Extreme  caution  and  care  has  been  used  in  order  to  eliminate  any 
prejudices,  personal  feelings  or  biases  from  the  development  of  this 
evaluation  process  and  its  subsequent  execution.  The  goal  is  to  identify 
solutions  without  regard  to  personal  preference;  however,  past  experience 
and  general  knowledge  will  be  an  Invaluable  source  of  information  and 
ideas. 
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The  general  desire  of  all  parties  Involved  In  this  project  and  of 
those  who  supplied  Input  Is  that  there  he  a  general  type  of  "environment" 
for  the  users  of  the  system.  It  should  be  easy  to  use  by  both  "program¬ 
mers"  and  "non-programmers"  while  fulfilling  the  needs  of  each.  The 
desire  of  easy  access  for  AFIT  personnel  seems  to  show  a  trend  away  from 
the  traditional  application  program  interface  for  users.  Based  upon 
these  feelings,  One  area  of  emphasis  will  be  on  "user  friendliness"  and 
che  non-procedural ity  of  the  package. 

A  DBMS  must  have  the  inherent  capabilities  to  provide  sufficient 
flexibility  to  support  a  dynamic  and  growing  organization  like  AFIT.  The 
need  exists  for  a  true  software  "utility",  that  is,  one  which  is  reli¬ 
able,  dependable  and  not  only  meets  current  needB  but  can  grow  with  the 
organization.  "The  capability  of  a  database  system  to  grow,  in  terms  of 
the  users  and  of  the  data  to  which  they  refer,  is  fundamental  to  the 
database  system  concept.  This  growth  may  be  achieved  in  many  directions 
and  dimensions.  The  necessary  requirement  is  that  a  data  base  package  be 
able  to  accommodate  modification,  variation  and  extension  of  the  database 
without  requiring  modification  of  all  currently  existing  programs  that 
use  it."  (REF  7  p  3.1.7) 

An  area  of  concern  which  is  second  to  none  is  the  ability  of  the 
DBMS  to  provide  a  level  of  security  which  can  guarantee  the  protection  of 
sensitive  information  while  not  unduly  restricting  access  to  those 
authorized  to  use  it.  Several  departments  expressed  a  need  to  safeguard 
their  data  in  order  to  protect  both  its  integrity  and  use.  While  only  a 
single  feature,  the  methods  and  degree  which  vendors  choose  to  use  in 
their  individual  implementation  of  security  make  this  area  one  that 
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should  be  investigated  closely 


2-1-  EVALUATION  PROCEDURE  and  SHEET 

As  stated  earlier,  the  evaluation  sheet  is  used  to  tally  or  record 
how  each  of  the  DBMSs  aeasured  against  a  set  of  fixed  criteria;  which 
were  determined  by  the  needs  of  AFIT.  The  goal  of  this  procedure  is  to 
evaluate  all  available  DBMSs  as  objectively  as  possible  by  assigning  a 
set  of  numbers  or  points  to  each  system  of  interest.  Once  completed,  the 
sum  of  these  scalars  will  be  used  to  “rank'*  the  individual  systems  in 
order  to  provide  a  basis  for  the  ultimate  selection  of  a  DBMS  for  imple¬ 
mentation  at  AFIT. 

By  using  the  resources  of  the  AFIT  library,  the  General  Services 
Administration  (CSA),  The  Air  Force  Directorate  of  Computer  Resources 
(AF/ACD)  and  others,  a  complete  list  of  commercially  available  DBMSs, 
plus  those  available  from  within  the  federal  government  will  be  compiled. 
Rased  upon  a  set  of  '’minimum’'  criteria  the  DBMSs  will  be  screened  to 
insure  that  only  those  systems  which  are  minimally  acceptable  will  be 
evaluated  further. 

Each  DBMS  will  be  measured  against  the  Items  on  the  evaluation  sheet 
(Appendix  IIA)  and  assigned  a  point  value  based  on  how  it  meets  the 
stated  criteria.  The  vendors'  literature  will  generally  be  the  basis  for 
these  determinations.  If  there  is  insufficient  data  available,  the  ven¬ 
dor  will  be  contacted  and  asked  to  supply  what  is  required.  Point  values 
will  be  assigned  by  first  comparing  the  DBMSs  against  tour  general  rules. 
These  rules  are:  1)  The  DBMS  exceeds  the  stated  criteria,  maximum  point 
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value  is  assigned;  2)  The  DBMS  meets  the  stated  criteria,  median  value 
assigned;  3)  The  DBMS  does  not  meet  the  stated  criteria,  a  zero  (low 
value)  is  assigned;  4)  The  DBMS  does  not  incorporate  the  feature  at  all, 
an  appropriate  negative  value  assigned. 

Once  this  rough  breakdown  has  been  completed  a  finer  evaluation 
based  upon  utility  and  effectiveness  of  the  DBMS  in  each  category  will  be 
performed.  In  so  doing  the  first  values  (if  any)  can  be  adjusted  up  or 
down  according  to  the  degree  to  which  the  basic  requirements  are  ful- 
filled. 

After  this  process  has  been  completed,  an  overall  value  for  each 
DBMS  will  be  computed  and  the  systems  ranked  according  to  this  total. 
The  top  DBMSs  will  be  given  as  recommendations  to  AF1T  for  further  con¬ 
sideration  concerning  acquisition  and  full  implementation.  It  is  from 
these  systems  that  it  is  anticipated  and  strongly  recommended  that  AFIT 
choose  a  DBMS  package.  Anything  else  might  quite  easily  result  in  a  sys¬ 
tem  which  cannot  cope  with  the  situation  and  requirements  of  AFIT.  These 
results  will  be  arranged  in  a  tabular  form  and  presented  to  the  CCB  as  a 
part  of  the  formal  recommendations. 


2*2^  Description  of  the  Evaluation  Sheet 

The  actual  evaluation  sheet  is  composed  of  three  major  sections, 
each  broken  into  detailed  subdivisions.  Each  section  corresponds  to  the 
areas  of  Interest  to  AFIT  and  their  relative  importance  is  emphasized  by 
a  unique  maximum  value  which  can  be  assigned  to  each  subdivision  withLn 
that  section.  This  type  of  arrangement  was  settled  upon  in  order  to 


insure  that  Che  “strongest"  DBMS,  i.e.  best  suited  to  AFIT's  needs,  would 
be  identified.  It  is  strongly  desired  that  no  single  factor  or  group  of 
factors  should  handicap  (either  positively  or  negatively)  a  particular 
DBMS.  It  is  recognized  that  ultimately  the  final  determination  as  to 
which  DBMS  is  to  be  implemented  rests  with  the  Computer  Resources  Direc- 
torace  (AFIT/ACD)  and  the  commander  of  AFIT,  and  will  involve  factors  not 
within  the  scope  or  nature  of  this  project. 

The  first  major  section  deals  with  those  “real  world"  considerations 
of  great  importance  to  AFIT.  Accordingly  a  maximum  weighted  value  of  10 
points  per  subdivision  is  used  for  emphasis;  this  shows  that  factors  so 
fulfilled  are  a  definite  advantage  to  a  DBMS.  Areas  of  consideration 
include  such  things  as  machine  compatibility,  current  availability  and 
cost.  These  were  chosen  because  they  are  of  the  type  which  will  play  a 
significant  role  in  ultimate  selection  of  the  DBMS.  Therefore,  it  was 
decided  that  they  carry  the  highest  maximum  point  value. 

The  second  major  section  is  concerned  with  the  operational  features 
of  a  DBMS.  This  section  is  designed  to  measure  features  which  are  impor- 
tant,  but  which  it  is  assumed  that  every  DBMS  will  incorporate  in  one  way 
or  another.  Therefore,  a  maximum  weighted  value  of  eight  points  per 
subdivision  is  used  to  help  distinguish  to  what  degree  they  are  avail¬ 
able,  how  well  they  work  and  how  easy  they  are  to  use  (according  to  all 
available  information). 

The  third  major  section  deals  with  items  which  are  available  with 
some  DBMS  packages  or  would  be  "nice  to  have"  but  are  not  required 
specifically.  It  was  felt  that  if  a  DBMS  possessed  any  of  these  features 
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it  would  be  a  plus  but  the  lack  thereof  should  not  be  a  detriment  from  an 
otherwise  desirable  package.  A  maximum  weighted  value  of  six  points  per 
subdivision  is  used. 

It  is  recognized  that  some  of  the  items  to  be  examined  are  more  sub¬ 
jective  than  are  others.  Every  attempt  has  been  made  to  reduce  these 
occurrences,  but  those  which  remain  will  be  evaluated  based  on  previous 
experience  and  the  consensus  of  others  with  more  experience  with  DBMSs. 


3^.2 .1_.  High  Priority  Considerations  (Section  I_ ) 


2*£»1_*_1  •  Current  Availability 

The  location  or  source  of  the  DBMS  is  scored  based  on  the  ease  of 
acquisition.  It  includes,  from  a  high  value  of  10  points  down  to  the  low 
value  of  two  points,  DBMSs  currently  located  at  another  WPAFB  organiza¬ 
tion,  another  Air  Force  installation/ facility ,  some  other  organization 
within  the  Federal  Government  and  those  commercially  available  only. 
DBMSs  currently  within  the  pervue  of  AFIT  will  score  the  maximum  value. 

_3.2_._1.2_.  Structure 

The  underlying  data  structures  and  asst  operators  the  DBMS 
will  support  is  a  crucial  question.  Database  systems  are  categorized 
according  to  the  particular  approach  which  is  adopted  in  answering  it. 
The  three  best  known  approaches,  relational,  hierarchical,  and  network 
will  be  used  as  a  basis  for  analysis.  (REF  10,  p  63)  In  accordance  with 
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a  significant  majority  of  the  academic  and  industry  opinions  and  trends, 
a  DBMS  which  is  based  upon  the  relational  concept  will  rate  the  highest 
value  possible  (10  points)  followed  by  network  (5  points)  then  hierarchi¬ 
cal  (2  points). 


3^2.1^.  AFIT  Computer  Systems  Compatibility 

Regardless  of  how  good  or  how  easily  available  a  DBMS  may  be,  if  it 
will  not  run  on  a  computer  system  currently  at  AF1T  or  projected  for 
acquisition,  then  its  utility  will  become  largely  academic.  The  greater 
the  number  of  systems,  at  AFIT,  which  could  host  a  DBMS,  the  higher  the 
score  for  that  system.  Current  AFIT  computer  systems  include:  CYBER  70, 
HARRIS,  VAX  11/780,  and  UNIX  on  the  DEC  11/60,  11/34  and  11/780.  In 
order  to  aid  in  the  office  automation  project  at  AFIT,  any  DBMS  which 
operates  under  the  UNIX  operating  system  will  receive  bonus  points. 

4.-2.-I-I- 

A  database  system  requires  core  memory  and  peripheral  storage  space; 
not  only  for  the  actual  data  of  Interest  to  me  users,  but  for  the  data¬ 
base  software  Itself.  For  the  system  to  operate  successfully  this 
implies  a  minimum  hardware  configuration  and  capacity.  (REF  7  p  3-6) 

There  are  three  general  questions  which  will  be  considered.  First, 
can  the  DBMS  concurrently  support  multiple  databases?  (4  points)  Second, 
does  it  use  the  host  computers  file  management  system  (access  method); 
versus  employing  a  unique  one?  (3  points)  Third,  is  there  a  limit  to  the 
number  of  records  or  bytes  which  the  system  can  handle  before  performance 
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begins  Co  degrade?  (3  points)  DBMSs  which  have  no  limit  will  receive 
maximum  points  with  the  actual  limits  determining  any  lesser  value. 
Scores  for  DBMSs  which  cannot  do  this  will  be  assigned  values  according 
to  the  particular  circumstances.  If  the  system  does  not  operate  with  the 
most  efficient  access  method  available  on  the  system,  the  score  will  be 
reduced  accordingly. 

One  important  consideration  which  cannot  objectively  be  assigned  a 
point  value,  but  will  be  listed  for  each  DBMS  is  the  amount  of 
storage/ memory  overhead  required  for  the  system  to  operate. 


5. 2. 1.3. 


No  score  will  be  assigned  for  this  factor.  The  dollar  figure  will 
be  listed  along  with  the  various  options  for  acquisition,  i.e.  purchase, 
lease,  etc.  Any  additional  charges  imposed  by  the  vendor  will  be  noted 
and  included  in  later  sections. 

Machine  Independence 

The  ability  to  enhance  or  change  a  computer  system  is  vital  to  a 
growing  and  changing  organization.  Likewise  the  ability  for  the  DBMS  to 
grow/change  is  also  an  important  factor.  It  should  be  able  to  cope  with 
hardware  and  operating  system  enhancements  as  well  as  offering  some  level 
of  portability  between  systems  with  the  same  operating  system.  The  more 
flexible  a  DBMS,  the  higher  the  score.  Factors  such  as  the  number  of 
different  machines  which  could  act  as  host  and  how  much  of  the  system 
must  be  changed  in  order  to  transfer  it  will  be  strongly  considered.  A 


DBMS  which  runs  under  the  UNIX  operating  syst<.&  is  considered  to  be  a 
highly  portable  system  and  will  receive  the  highest  score. 

J>.2^ 1_. 5^.  Data  Dictionary 

A  data  dictionary  (DD)  generally  serves  two  purposes  within  a  DBMS. 
The  first  is  the  collection  and  dissemination  of  data  about  the  structure 
of  the  database,  as  well  as  the  data  Itself.  Secondly,  it  serves  as  a 
tool  by  which  database  standards  can  be  imposed  and  enforced.  Such  areas 
include  data  element  names  and  usage,  coding  conventions,  security,  and 
database  monitoring  and  statistics  gathering.  (REF  2,  p  6) 

The  closer  a  DBMS  is  tied  to  its  data  dictionary,  the  higher  the 
score.  If  the  DD  is  a  strongly  integrated  part  of  the  system  and  its 
operation,  the  highest  score  will  be  assigned.  If  the  DD  is  an  optional 
or  ancillary  feature,  the  score  will  be  reduced  accordingly  because  the 
DBMS  itself  could  be  used  to  construct  and  maintain  a  DD  through  custom 
applications  programs. 


5^2_.^2.  Important  Operational  Features/Considerations  (Section  II ) 


5_.2 .2 .  K  Application  Languages 

The  programming  Interface  which  the  DBMS  supports  represents  an 
Important  aspect  of  implementation.  Researchers  have  classified  these 
interfaces  into  two  broad  categories.  The  self  contained  DBMS  is  charac¬ 
terized  by  a  special  language  facility  (data  manipulation  language  op 
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DML)  but  a  host  language  DBMS  Is  based  upon  a  high  order  language  (HOL) 
and  employs  its'  "call"  facility  to  support  the  DBMS  commands.  By  using 
the  DBMS  *  unique  DML,  applications  programs  become  dependent  on  the 
facilities  of  a  particular  DBMS.  While  this  may  be  an  advantage  for  the 
vendor,  it  inhibits  the  flexibility  of  the  user.  In  general,  the  commer¬ 
cial  DBMSs  which  provide  for  the  host  language  capability  have  proven 
much  more  successful  than  those  with  only  a  self  contained  capability. 
(REF  2,  pl5) 

The  ability  of  a  DBMS  to  support  applications  languages  and  the 
number  supported  will  be  evaluated  according  to  the  following  criteria. 
One  point  will  be  assigned  for  each  HOL  a  DBM:  will  Interface  with,  and 
one  additional  point  if  it  is  currently  supported  within  AF1T.  Five 
points  will  be  deducted  If  the  DBMS  does  not  have  a  HOL  interface  and 
employs  a  "unique”  interface  to  the  database. 

2*i*l*l*  Privacy  and  Security 

Privacy  refers  to  the  protection  of  a  database  from  unauthorized 
use,  and  security  refers  to  the  protection  from  both  overt  and  inadver¬ 
tent  destruction.  The  implementation  of  these  concepts  often  operates  at 
various  levels  ranging  from  protection  of  the  full  database  to  indivi¬ 
dual,  single  files  only  or  it  may  cover  various  combinations  of  structure 
data  for  logical  organization.  Some  systems  go  to  such  extremes  as  res¬ 
tricting  the  user  from  any  access  to  the  structure  data  and  others  allow 
various  combinations  depending  on  special  authorization  Levels.  (REF  7, 
P  3-2) 
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The  security  and  privacy  features  available  on  the  DBMS  will  be 
investigated  by  applying  the  following  criteria.  Two  points  will  be 
assigned  for  each  of  the  following  four  areas.  1)  Does  the  DBMS 
provide/ control  access  to  the  database  ltseli  (password,  person— id)?  2) 
Does  the  DBMS  provide/control  access  to  files,  records  and/or  attributes? 
3)  Does  the  DBMS  provide/control  access  to  the  logical  view  of  the  data? 
A)  If  passwords  are  used,  are  they  system  generated  and  can  the  user 
change  them?  Points  will  be  subtracted  if  the  security  features  rely 
explicitly  on  the  operating  system  and  if  the  data  base  itself  can  be 
destroyed  or  damaged  from  within  or  without  the  operating  system. 

5^ .2^.2^. _3.  Backup  and  Recovery 

It  is  evident  that  we  cannot  rely  on  the  indefinite  preservation  of 
the  data  in  a  database.  Data  in  the  machines  registers  or  solid  state 
memory  cannot  be  presumed  to  survive  a  power  outage,  for  example. 
Further,  no  data  is  completely  safe  from  being  obliterated  by  system 
software  errors.  For  these  reasons,  it  is  essential  that  backup  copies 
of  the  database  be  made  periodically,  at  least  once  a  day  if  possible. 
The  copy,  on  a  tape  or  disk,  should  be  removed  from  the  vicinity  of  the 
computer  and  stored  in  a  safe  place. 

When  making  a  copy,  it  is  important  that  the  copied  data  represent  a 
consistent  state.  (REF  17,  p  352-353)  Recovery  functions  depend  on  two 
basic  steps.  The  first  is  reconstruction  of  the  data,  and  the  second, 
reestablishing  the  relationships  among  the  various  records  of  the  data¬ 
base  so  as  to  include  all  modifications  up  to  the  failure  point.  (RKF  7, 
P  3-2) 
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Of  priaary  concern  Is  Che  safety  of  Che  database  to  failure  and  how 
reliable  will  it  be  once  restored  after  a  DBMS  or  system  software  error. 

The  thoroughness  and  effectiveness  of  the  backup  and  recovery  facil- 
ities  of  the  DBMS  will  be  examined  by  the  following  procedure.  One  point 
will  be  assigned  for  each  of  the  following  criteria.  1)  Are  the  recovery 
procedures  automatic  (2  pts)  versus  user  initiated  (1  pt)?  2)  Is  the 
database  safe  from  being  damaged  beyond  beyond  repair?  (subtract  one 
point  if  it  makes  a  difference  if  the  database  was  in  use  at  the  time) 
3)  Does  the  vendor  offer  any  guarantees  or  assistance  in  the  event  of  an 
accident?  4)  does  the  DBMS  offer  facilities  for  backup  (either  automatic 
or  manual)  instead  of  using  other  methods  available  from  the  host  com** 
puter  system?  5)  Does  the  DBMS  maintain  transaction  logging  and  are  the 
files  available  to  the  general  user  (Before  transaction  logging  ■  1  pt 
and  After  transaction  logging  *  1)?  6)  Can  the  transaction  logging  be 
turned  on  and  off  (subtract  one  point)?  7)  Is  the  logging  done  without 
adversely  affect  the  response  and  efficiency  of  the  DBMS  software? 

^.2.2.4.  Structure  Definition 

Each  DBMS  must  provide  a  means  by  which  the  DBA  describes  the  indi- 
vldual  fields,  their  format  and  the  conditions  for  access  and  any  logical 
relationships.  This  mechanism  is  usually  called  a  database  description 
language  (DDL)  and  is  often  a  stand-alone  facility  and  it  is  via  this 
that  the  construction  of  the  database,  as  the  user  "sees"  it,  is 
achieved.  (KEF  7,  p  3-6)  These  programs  can  either  build  tables  that  are 
accessed  by  the  DBMS  at  run  time  or  generate  code  modules  that  are 
entered  by  the  DBMS  at  run  time;  the  choice  is  made  by  the  DBA.  (REF  2, 


PACE  58 


The  DBMS  software  often  gives  the  user  many  options  which  may  be 
Incorporated  at  the  tine  of  [database]  Installation.  Such  items  as  the 
number  of  files,  file  names,  data  space  sizes,  types  of  access  methods, 
physical  file  organization  must  be  considered.  All  these  factors  must 
come  together  to  install  a  database  into  an  operating  system  on  a  host 
computer.  (REF  7,  p  3-11) 

How  easy  it  is  for  the  DBA  to  define  and  Install  a  database  will  be 
evaluated  with  the  following  procedure.  Two  points  will  be  assigned  for 
each  of  three  main  areas.  They  are:  1)  Can  tne  database  definition  be 
accomplished  using  macro  procedures  or  file  inputs?  2)  Once  established, 
can  the  structure  be  used/queried  by  authorized  users?  3)  Is  the  process 
of  defining  a  database  simple  and  automatic  or  is  it  a  difficult  manual 
task? 

.2^ .J>.  Modifiability  of  the  Structure 

In  a  changing  environment  the  database  often  must  be  expanded  or 
changed  in  order  to  meet  new  user  requirements.  Once  the  database  has 
been  Installed  and  loaded  with  data,  changing  the  structure,  adding  files 
or  changing  their  description,  can  be  a  potentially  dangerous  major 
effort.  Large  amounts  of  data  must  be  moved  or  changed  and  some  may  be 
lost  or  left  lrrepairably  damaged  if  the  modification  is  not  done 
correctly  and  precisely. 

The  ease  and  simplicity  with  which  the  DBA  can  change  the  structure 
of  a  database,  once  Installed  and  loaded,  will  be  examined  by  the 


following  criteria.  Two  points  will  be  assigned  for  each  of  the  follow¬ 
ing  areas:  1)  Can  attributes  be  added/deleted  without  undue  impact  on 
the  remainder  of  the  database?  2)  Can  files  be  added/deleted  without 
undue  impact  on  the  remainder  of  the  database?  3)  Can  logical  views  be 
easily  modified?  4)  Can  the  database  be  modified  interactively  without 
rendering  the  database  unusable  during  the  process? 

b'2.2.5. 

Because  the  database  utilizes  a  file  system  within  an  operating 
system,  certain  functions  must  be  performed  periodically  to  guard  against 
wasting  large  amounts  of  space  due  to  deletion  of  data.  Such  wasted 
space  can  have  adverse  effects  on  the  efficiency  and  response  time  of  not 
only  the  database  Itself  but  also  on  the  host  computer.  Some  measures 
must  be  taken  to  insure  that  the  database  is  "healthy'*  and  is  as  effi¬ 
cient  as  possible.  Normally  these  measures  are  transparent  to  the  DBA, 
handled  automatically  by  the  DBMS  and  no  thought  is  given  to  their  opera¬ 
tion.  Unfortunately  some  DBMSs  do  not  incorporate  such  features  and  the 
DBA  must  rely  on  certain  operating  system  facilities  to  specifically 
adjust  the  files  and  remove  wasted  record  areas. 

Whether  a  DBMS  supplies  automatic  compensations  for  the  addition  and 
deletion  of  data  will  be  evaluated  using  the  following  procedure.  Two 
points  will  be  assigned  for  each  of  the  following  three  criteria:  1)  Must 
the  database  files  be  reorganized  periodically?  2)  Are  these  procedures 
automatic?  3)  Can  the  DBA  make  the  database  more  efficient?  (tunabllity) 
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6^.2^£.  User  Friendliness  &  Facilities 

The  user/system  Interface  (US1)  is  a  critical  element  of  a  DBMS,  for 
without  it  the  system  will  inadequately  serve  its  users.  Without  the 
appropriate  interfaces  for  various  levels  of  users  the  database  will  fall 
into  disuse.  Among  these  Important  factors  are  two  which  are  vital  to 
the  users.  They  are  language  and  interactive  capabilities . 

The  utilization  of  natural  language  for  communicating  with  the  sys¬ 
tem  will  enhance  the  ability  of  users  to  formulate  requests  and  problem 
definitions.  An  Interactive  capability  will  make  it  possible  to  compli¬ 
ment  the  human  thought  process  and  aid  management  in  its  decision  making 
activities.  (REF  2,  p  7) 

The  friendliness,  ease  of  use  and  non-procedural ity  of  a  DBMS  will 
be  Investigated  using  the  following  criteria.  One  point  will  be  assigned 
for  each  of  the  following  areas:  1)  Is  th'  DBMS  non-procedural  and 
oriented  toward  non-programmers?  2)  Does  it  use  an  engllsh  language 
approach?  3)  Can  the  users  get  documentation  or  help  on-line?  4)  Is  the 
use  of  the  DBMS  independent  of  the  users'  knowledge  of  the  underlying 
structure  of  the  database?  5)  Does  it  offer  any  interfaces  to  text  or 
file  processing  facilities?  6)  Is  it  generally  user  friendly  with 
regards  to  errors  and  mistakes?  7)  Can  queries  or  other  operations  be 
"canned"  or  saved  for  future  use?  8)  Can  functions  be  used  within  the 
query  language  itself  and  are  there  any  supplied  by  the  vendor? 
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The  nature  and  complexity  of  a  DBMS  occasionally,  depending  on  the 
hardware  and  particular  implementation,  will  require  special  modifica¬ 
tions  or  specific  hardware  in  order  to  run  correctly.  On  the  other  hand 
the  features  of  a  given  DBMS  will  often  allow  it  to  support  some  special 
hardware  such  as  graphics  terminals  or  plotters. 

Two  points  will  be  subtracted  for  each  piece  of  special  hardware 
required  by  the  DBMS.  Two  points  will  be  assigned  for  each  piece  of  spe¬ 
cial  hardware  which  the  DBMS  can  support  without  modification  of  the 
software. 

6_._2.2_._8.  Update/Retrieval  Protocol 

Ideally,  a  database  system  should  permit  unrestricted  access  of  all 
users/ prog rams  to  any  data  that  they  are  authorized  to  use.  This 
presents  no  difficulties  when  several  users/programs  attempt  to  retrieve 
data  from  the  same  file;  the  complications  arise  when  more  than  one 
wishes  to  change  the  database.  (REf  16,  p  2-27)  Intuitively,  two  pro¬ 
cess  that  read  and  change  the  value  of  the  same  object  must  not  be 
allowed  to  run  concurrently. 

Actually,  transactions,  when  executed  concurrently,  give  rise  to 
dangerous  situations  such  as  live-lock,  dead-lock  and  nonserlalizabil ity . 
(REP  17,  p  324,331)  Each  of  these  is  a  product  of  the  DBMS  trying  to 
prevent  concurrent  operations,  resulting  i  .  one  or  more  users/ programs 
being  temporarily  prevented  from  accessing  the  required  data.  The 
methods  by  which  these  are  handled  by  various  DBMSs  is  by  no  means 
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consistent,  nor  In  some  cases,  desirable.  Whether  a  particular-  ’MS  will 
adequately  support  concurrent,  multiple  queries  and  updates,  aua  how  well 
it  does  it,  is  s  vital  question  in  an  environment  where  many  users  will 
access  the  database  daily. 

The  following  criteria  will  determine  which  DBMS  adequately  support 
multiple  query  and  update  functions.  Two  points  will  be  assigned  for 
each  of  the  following  criteria  which  the  DBMS  can  fulfill.  1)  Can  the 
DBMS  support  multiple  query  and  single  update?  2)  Can  the  DBMS  support 
multiple  query  and  multiple  update?  3)  Is  the  DBMS  multi- threaded?  4) 
Once  a  process  is  locked  out  of  a  file,  will  the  DBMS  automatically  rein¬ 
itiate  the  action  before  returning  with  an  error? 

6_.2_.2_.9_.  Report  Generator 

The  availability  and  use  of  a  report  gen -rater  can  drastically  shor¬ 
ten  development  time  for  most  applications.  It  can  provide  assistance  to 
users  in  placing  the  output  from  a  database  into  the  most  humanly 
comprehensible  form.  Raw  data  selected  from  the  database  can  be  sorted 
and/or  broken  down  as  the  user  requires  and  the  format,  headings  or  order 
easily  changed  as  desired.  However,  not  all  commercial  DBMSs  are  pack¬ 
aged  with  such  a  facility.  In  these  cases  it  is  necessary  that  the  DBMS 
provide  an  adequate  interface  to  a  separate,  external  report  generator 
package. 

Three  points  will  be  assigned  for  the  fi.st  two  general  criteria, 
and  two  points  for  the  third  general  criteria.  1)  Does  the  DBMS  have  a 
report  generator  which  is  integrated  into  the  system?  2)  Is  it  an  easy 
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co  use,  non-procedural  facility?  3)  Does  it  support  the  use  of  macros? 
j  Any  limiting  factors  which  are  discovered  will  have  appropriate  points 

subtracted . 

|  6.2.2.10.  Vendor  Support 

While  not  essential  to  the  actual  operation  of  a  DBMS,  vendor  sup¬ 
port  can  ease  the  burden  and  problems  associated  with  transitioning  to  a 
^  new  software  system.  Many  hours  of  research  and  study  can  be  eliminated 

if  a  vendor  provides  adequate  training  and  assistance  during  and  after 
the  implementation  of  the  software  and  subsequent  databases.  Addition¬ 
ally,  just  as  with  any  other  product,  the  “service  after  the  sale*'  will 
provide  much  needed  help  in  situations  such  as  hardware  changes  and/or 
enhancements  and  repairs  to  both  the  operating  system  and  DBMS  software. 

I  <0 

The  following  criteria  will  determine  hov  much  assistance  a  vendor 
is  willing  to  provide  those  who  have  acquired  his  DBMS.  Points  will  be 
\  assigned  as  follows:  1)  Will  or  does  the  vendor  provide  training?  (2 

points)  2)  Is  the  vendor  available  at  any  time  to  answer  questions  or 
solve  problems?  (2  points)  3)  Is  there  an  established  users  group?  (2 
I  points)  4)  Will  the  vendor  repair  or  modify  the  DBMS  software  as 

required?  (1  point)  5)  Will  the  vendor  provide  updates  co  the  DBMS  as 
new  features  are  developed?  (1  point)  One  point  will  be  subtracted  for 
I  each  item  for  which  the  vendor  requires  an  additional  charge  over  and 

above  the  cost  the  the  DBMS. 

I 
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7.2.2.10. 


Every  software  vendor  has  some  kind  of  documentation  available  for 
his  product.  However,  the  quality  and  usefulness  of  the  work  plus  the 
price  and  availability  will  vary  greatly.  In  an  environment  such  as  AK1T 
where  there  will  be  many  users  of  varied  backgrounds,  each  performing 
unique  tasks,  the  existence  of  adequate  documentation  is  essential.  It 
would  relieve  a  great  deal  of  tension  and  frustration  from  the  users  if 
problems  can  be  solved  and  questions  answered  quickly  and  with  a  minimum 
of  trouble. 

The  following  criteria  will  determine  whether  or  not  the  vendor  of  a 
particular  DBMS  can  provide  AFIT  with  adequate  documentation  of  his  pro¬ 
duct.  Points  will  be  assigned  for  each  of  the  three  following  criteria 
as  follows:  1)  Is  the  documentation  clear,  readable  and  easy  to  use?  (3 
points)  2)  Does  it  answer  questions  which  the  majority  of  average  users 
would  be  concerned  with?  (2  points)  3)  Is  any  of  the  documentation 
available  on-line?  (3  points)  Two  points  will  be  deducted  if  the  vendor 
charges  extra  for  documentation  or  for  more  than  a  few  copies. 


7_.2^3i .  Desirable  Features  (Section  III ) 

Batch/On-llne  Operation 

The  flexibility  of  a  DBMS  is  partially  determined  by  the  methods  by 
which  users  can  access  the  data.  If  users  are  restricted  to  only  a  sin¬ 
gle  mode  of  operation,  delays  can  be  Incurred  by  requests  which  require 
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either  long  or  very  short  periods  of  time  in  which  to  be  accomplished. 
Ideally  a  DBMS  should  be  flexible  enough  to  allow  a  user  the  option  of 
performing  his  tasks  while  on-line  and  waiting  for  the  results  or  asking 
the  DBMS  to  perform  the  job  in  a  remote  or  batch  environment. 

Two  points  will  be  be  awarded  for  any  DBMS  which  meets  the  following 
criteria:  1)  Is  the  DBMS  oriented  toward  on-line  operation?  2)  Can  the 
DBMS  support  batch  operations?  3)  Can  the  DBMS  support  both  batch  and 
on-line  operations  concurrently? 

7 .2^2*2.  Utllltles/Functlons 

The  ability  to  perform  complex  or  redundant  procedures  in  a  quick 
and  easy  manner  can  be  an  invaluable  aid  to  the  users  of  a  DBMS.  Utili¬ 
ties  which  allow  certain  mathematical  and/or  logical  operations  on  the 
data  as  well  as  those  which  ease  textual  manipulation  will  increase  the 
DBMSs  usefulness  to  the  user  as  well  as  increasing  his  productivity.  For 
example,  it  is  often  desirable  to  initialize  a  database  with  data  from 
other  existing  files.  A  facility  for  automatically  converting  a  non¬ 
database  file  into  a  form  which  is  readily  moved  into  the  database  would 
be  highly  useful.  (KEF  7,  p  3.1.5) 

The  kindB  and  type  of  utilities  are  not  of  interest  as  much  as  the 
ability  of  the  DBMS  to  use  them.  If  a  DBMS  easily  supports  utilities  aid 
functions,  users  may  freely  create  as  many  as  they  wish  to  satisfy  their 
needs.  One  point  will  be  assigned  to  a  DBMS  which  fulfills  each  ot  the 
following  criteria:  1)  Does  the  DBMS  provide  for  utilities  and  func¬ 
tions?  2)  Can  the  user  create  his  own  utilities  and  functions?  3)  Are 
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these  utilities  permanently  available  until  removed  by  the  creator?  4) 
Can  these  utilities  be  shared/used  by  others?  5)  Does  the  vendor  pro¬ 
vide  a  set  of  utilities  for  the  DBMS  and  its  operation? 

_7  •£. Accounting  Facilities 

Certain  users  of  the  proposed  AFIT  database  have  expressed  a  desire 
to  perform  accounting  activities  in  conjunction  with  their  normal  data¬ 
base  activities.  If  available,  any  DBMS  which  Incorporates  such  a  facil¬ 
ity  will  be  awarded  six  points. 

_7  .2.3.4.  F leld  Value  Enforcement  (data  integrity) 

There  are  generally  two  types  of  problems  associated  with  the 
maintenance  of  data  integrity.  First  is  the  problem  of  the  correct  type 
of  data  for  a  specified  field,  e.g.  alphanumeric,  binary,  etc.  The 
second  relates  to  the  value  of  the  data  to  be  placed  in  the  fields.  For 
example,  there  may  be  automatic  facilities  in  the  DBMS  which  specifies 
that  a  data  value  may  not  exceed  a  certain  range.  (REF  7,  p  3-2) 

The  ability  of  the  DBMS  to  assist  in  maintaining  data  integrity  will 
be  investigated  by  the  following  criteria.  One  point  will  be  assigned  to 
a  DBMS  which  fulfills  each  of  the  following  criteria:  1)  Will/does  the 
DBMS  enforce  field  values?  2)  Will/does  the  enforce  data  types?  3) 
Is  this  defined/changed  by  the  DBA  instead  of  the  user?  4)  Does  the  DBMS 
notify  the  user  clearly  and  accurately  as  to  what  has  happened?  3)  Can 
the  parameters  be  examined  by  the  user? 
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7^.2,  .jLJ>.  Key  Value  Enforcement 

Each  DBMS  which  enforces  the  uniqueness  of  predefined  key  fields 
will  be  assigned  six  points*  If  there  is  a  limit  to  the  number  of  key 
fileds  which  may  be  defined  in  a  given  record,  one  or  two  points  will  be 
deducted  depending  upon  the  amount. 

7^_2  •  Secondary  Indexing 

If  a  particular  DBMS  allows  for  secondary  indices  to  be  placed  upon 
the  attributes  within  a  record,  three  points  will  be  assigned.  Ability 
to  fully  invert  the  structure  will  merit  another  three  points. 

7^2^2*2.*  User  Usage  Statistics 

The  DBA  or  other  authorized  levels  of  management  often  are  concerned 
with  the  number  and  frequency  of  accesses  to  the  database.  Areas  such  as 
time  and  type  of  query,  which  users  (by  department)  access  the  database 
and  what  files  they  use  are  commonly  of  interest.  If  the  DBMS  has  facil¬ 
ities  for  maintaining  these  types  of  statistics,  six  points  will  be 
awarded. 


7.3.  RESULTS  and  CONCLUSIONS 


General  Procedure 

As  much  Information  about  available  DBMSs  was  gathered  from  a  wide 
variety  of  sources  as  was  possible.  The  most  valuable  was  an  article 
which  appeared  in  a  September  1981  issue  of  DATAMATION  (REF  11)  which 
presented  a  short  synopsis  of  each  of  DBMS  on  the  market.  With  this  as  a 
guide,  further  information  was  gathered  as  required  from  other  sources, 
such  as  DATAPRO  and  other  articles  in  periodicals.  Several  weeks  were 
devoted,  in  whole  or  part,  to  studying  this  data  and  talking  to  several 
vendors  in  order  to  gain  a  thorough  understanding  of  the  available  DBMSs 
and  what  the  current  state-of-the-art  is. 

The  evaluation  was  carried  out  by  searching  for  answers  to  the  set 
of  questions  in  the  evaluation  section  (Section  3.2.1)  and  assigning 
points  according  to  the  pre-defined  rules.  When  there  was  no  data  or  the 
data  was  insufficient  so  that  a  firm  determination  could  be  made  concern¬ 
ing  a  item,  a  value  of  zero  was  assigned.  In  some  cases  the  vendor  was 
contacted  for  clarification  and  additional  detailed  information  on  those 
DBMSs  which  scored  a  70  or  higher  (the  top  14  systems)  on  the  evaluation 
was  requested.  The  total  values  were  calculated  for  each  DBMS  and  they 
ranked  accordingly  (Appendix  I IB).  A  chart  showing  how  each  DBMS  scored 
In  each  category  may  be  found  in  Appendix  1IC. 

7 .3^.  1_,  General  Comments  on  the  Procedure 

Across  the  board  there  is  little  specific,  detailed  Information 
available  to  the  public  on  DBMSs.  There  are  several  sources  from  which 
very  general  Information  may  be  obtained,  but  little  of  the  type  required 
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by  this  evaluation.  DATAPRO  has  a  fairly  detailed  breakdown  on  DBMSs 
(including  most  of  what  was  needed  for  those  systems  they  listed),  but 
mainly  on  those  systems  oriented  toward  IBM  and  ocher  larger  computer 
systems.  It  appears  that  a  large  segment  of  the  market  has  been  over¬ 
looked  and  DATAPRO's  descriptions  exclude  many  "recent"  and  very  capable 
systems.  Sometimes  that  information  which  was  available  was  ambiguous  or 
misleading  as  to  'the  actual  capabilities  and  functions  of  the  DBMS. 

Another  aspect  which  was  difficult  to  pin  down  were  the  DBMSs  which 
were  available  from  within  the  Federal  Government.  The  General  Services 
Administration  (GSA)  Federal  Software  Exchange  program  either  did  not 
contain  the  desired  information  or  simply  did  not  list  possible  systems. 
One  DBMS  (RIM)  which  was  written  under  a  government  contract,  known  by 
the  author  and  others  at  AFIT,  was  evaluated  but  did  not  appear  on  the 
list.  This  most  likely  Is  a  failure  on  the  part  of  the  organizations  to 
list  their  systems  and  not  on  the  system  Itself. 

The  evaluation  as  discussed  In  Section  3.2.1  generally  turned  out  to 
be  too  detailed  for  the  level  of  information  received..  Even  though  the 
items  to  be  evaluated  are  crucial  to  the  smooth  and  efficient  operation 
of  a  DBMS,  vendors  usually  do  not  widely  publish  sufficient  details  on 
the  operation  of  their  product.  In  those  instances  where  a  vendor  was 
contacted  and  asked  specific  questions  (from  the  evaluation  sheet),  they 
readily  supplied  the  information.  Because  of  this  situation,  this 
evaluation  could  only  be  10QZ  fair  and  complete  If  each  vendor  is  con¬ 
tacted  individually  and  asked  the  set  of  questions.  As  if  r.nr  w-  1  .  ,?  , 

li jv:vi:r,  those  systems  which  were  rated  low  because  ot  a  lack  of  intorma- 
tion  probably  could  not  been  considered  as  likely  candidates  because  the 
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type  of  computer  which  could  support  them  was  limited  or  other  signifi¬ 
cant  features,  for  which  there  was  sufficient  data,  could  not  fulfill 
AFITs  needs  anyway. 

In  spite  of  the  lack  of  data  in  some  areas  and  because  of  the  way  in 
which  the  evaluation  was  structured  it  is  felt  that  those  systems  which 
scored  the  higher  points  are  the  most  suitable  for  AF1T.  It  is  felt, 
very  strongly,  that  the  evaluation  was  sufficiently  encompassing  and  well 
rounded  to  adequately  reflect  the  needs  of  AFIT.  Additionally,  as  was 
hoped,  the  best  possible  DBMSs  were  identified  through  a  fair  and  impar¬ 
tial  process. 

7^.3. 3.  Conclusions 

Several  Important  conclusions  were  reached  during  the  course  of  this 
evaluation.  They  fall  into  two  general  categories.  One  deals  with  AFIT 
Itself  and  the  other  concerns  the  DBMS  market. 

Most  important  is  the  fact  that  the  capabilities  which  AFIT  requires 
of  a  DBMS  are  well  within  the  current  state-of-the-art  in  DBMS  technol¬ 
ogy.  The  systems  now  being  marketed  are  extremely  sophisticated  and 
written  mainly  for  the  non-programmer.  They  provide  a  great  deal  of 
flexibility  for  the  user  and  the  organization  alike  in  both  the  manipula¬ 
tion  of  the  data  and  the  database  structure  itself.  Additionally,  they 
virtually  all  but  eliminate  the  need  for  applications  programs  in  organi¬ 
zations  which  have  information  requirements  similar  to  AFIT.  lixtrcmely 
sophisticated,  english  like  query  facilities  combined  with  good  security 
measures,  report  generators  and  accounting  capabilities  provide  a  DBMS 
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which  can  be  virtually  tailored  to  the  individual  users. 


Two  less  significant  facts  were  also  discovered.  As  far  as  industry 
views  databases  and  their  uses,  AF1T  represents  a  rather  small  applica¬ 
tion.  This  is  in  spite  of  the  potentially  large  amount  of  data  which 
will  be  in  the  database.  Database  applications  are  generally  classified 
by  the  amount  and  frequency  of  queries  levied  against  the  data.  Even  at 
peak,  usage,  AFIT  will  not  amount  to  a  significant  level,  as  defined  by 
industry.  Another  thing  learned  was  that  AFIT  lias  a  rather  unusual  mix¬ 
ture  of  computer  hardware  on  which  to  implement  a  DBMS.  There  are  a  lim¬ 
ited  number  of  DBMSs  currently  available  which  can  run  under  the  UNIX 
operating  systems.  However,  those  which  are  available  are  very  powerful 
and  popular.  As  few  as  these  were,  the  number  of  DBMSs  capable  of  run¬ 
ning  on  the  HARRIS  minicomputer  are  fewer  still.  This  situation  severely 
limits  the  range  of  possible  DBMS  candidates  for  AFIT. 

Because  of  the  large  number  of  DBMSs  which  were  evaluated,  some  gen¬ 
eral  observations  may  be  made  about  the  macket  as  a  whole.  Primarily, 
there  are  many  good  DBMSs  which  will  more  than  satisfy  AFIT's  require¬ 
ments,  and  at  reasonable  price. 

Secondly,  the  majority  of  the  DBMS  market  appears  to  be  oriented 
toward  IBM  and  DEC  hardware.  This  is  not  all  to  surprising  because  these 
two  vendors  manufacture  the  majority  of  hardware  presently  in  use 
throughout  the  world.  On  the  other  hand,  there  does  seem  to  be  a  treni 
by  smallei  software  companies  to  fill  the  gap  and  provide  capable  and 
reliable  DBMSs  for  a  larger  variety  of  hardware  and  operating  systems. 
It  is  probably  safe  to  state  that  there  is  at  least  one  DBMS  which  will 
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operate  on  almost  every  computer  currently  commercially  available.  This 
does  not  necessarily  Include  microcomputers  even  though  they  too  are 
being  quickly  accounted  for. 

7..  3. 4^  Recommendations 

Recommendations  for  the  DBMS  to  be  utilized  within  AFIT  to  support 
CADIS  are  based  upon  the  current  hardware  configurations  at  AFIT,  the 
information  requirements  and  performance  characteristics  expressed  in  the 
interviews  as  well  as  the  current  state  of  DBMS  technology. 

It  was  determined  at  the  conclusion  of  the  evaluation  procedure  that 
those  system  which  scored  a  70  or  higher  were  to  be  considered  as  prime 
candidates  for  implementation.  These  systems  are  the  top  14  systems  out 
of  44  evaluated.  Cost  figures  are  not  included  in  the  recommendations 
nor  were  they  considered  heavily  because  a  specific  price  must  be  nego¬ 
tiated  with  the  vendor  and  might  very  well  be  lower  or  higher  than  that 
quoted  in  the  literature,  depending  on  the  individual  situation. 

No  single  specific  recommendation  for  the  DBMS  or  computer  system 
has  been  given.  What  .  has  been  done,  however,  is  a  list  of  the  best 
alternatives,  as  viewed  by  the  authors,  has  been  drawn  up  from  which  the 
final  choice  might  be  made.  This  will  allow  the  alternative  which  best 
suites  AFIT  at  the  time  to  be  used.  The  following  are  recommended  as 
possible  solutions  for  the  implementation  of  CADIS: 

(1)  Acquire  the  ORACLE  DBMS,  currently  on  the  CSA  price  schedule,  and 

implement  it  on  the  PUP  11/34,  PDP  11/60  or  VAX  11/7 iiO  under  the 


UNIX  operating  system 


*r 


(2)  Acquire  Che  SEED  DBMS,  currently  on  Che  CSA  price  schedule,  and 

etcher  remove  UNIX  from  one  of  che  PDPs  and  reinstall  the  original 

operating  system  (SEED  does  noc  yet  run  under  UNIX)  or  acquire 
another  DEC  computer  system  or  some  other  which  will  run  SEED. 

(3)  Acquire  SEED  and  negotiate  with  the  vendor  to  make  it  run  on  the 

HARKIS  mini  computer.  The  vendor  has  stated  that  this  is  possible, 

and  they  are  considering  it  now,  but  the  actual  cost,  if  any,  would 
have  to  be  negotiated. 

(4)  Acquire  a  complete  TOTAL  DBMS  package  and  install  it  on  the  HARRIS. 
The  package  available  from  AF1T/EN  Is  not  complete  and  would  not 
fulfill  the  needs  of  the  users  because  those  modules  which  make  it 
so,  like  the  query  facility  and  data  dictionary,  are  separately 
priced  items  and  must  be  acquired  as  such. 

(5)  Acquire,  or  reach  a  usage  agreement  with  a  WPAFB  organization  for 
the  use  of,  a  PRIME  computer  system  and  Inscall/use  the  INFO  DBMS. 

(b)  Acquire  the  latest  version  of  the  RIM  DBMS,  currently  available  from 
BOEING  Computer  Co.  under  a  NASA  contract,  and  install  it  on  the  VAX 
11/780  in  AFIT/EN.  Under  this  option,  communications  would  have  to 
be  provided. 

(7)  Acquire  an  IBM  System  38  Database  Computer. 


The  two  highest  ranking  DBMSs,  ORACLE  and  SEED,  are  almost  equally 
qualified  for  implementation  of  CADIS,  and  should  be  used.  The  capabili¬ 
ties  and  functions  of  each  are  almost  identical  in  all  respects.  Each 
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has  an  advanced  level  of  data  security,  a  data  dictionary,  fully  capable 
report  generators,  database  and  data  maintenance  facilities  and  a  highly 
sophisticated  and  useful  CRT  screen  formating  facility  for  applications 
development . 

Two  of  the  most  significant  features  of  these  DBMSs  are  the  security 
and  CRT  screen  formator.  Security  is  controlled  not  only  with  passwords 
and  person-ids  to  the  attribute  level  at  least,  and  one  (ORACLE)  allows 
the  logical  data  views  to  specify  restrictions  on  a  subset  of  data  within 
a  relation,  such  as  STUDENTS.  This  means  that  each  directorate  can  con¬ 
trol  the  privileges  on  their  data,  not  only  for  themselves  but  for  the 
rest  of  AF1T  as  well.  As  far  as  can  be  determined,  these  are  the  only 
DBMSs  currently  available  which  offer  such  extensive  and  flexible  secu¬ 
rity  measures  (others  merely  allow  password  and/or  person-id  protection). 

Almost  as  significant  as  the  strong  security  is  the  existence  of  an 
easy  to  use  (user  oriented)  and  very  capable  CRT  screen  formator.  This 
feature  could  all  but  eliminate  the  need  for  applications  programs  at 
AFIT.  With  the  use  of  any  CRT  which  allows  for  direct  cursor  addressing, 
a  user  may  designate  protected  and  unprotected  areas  for  data  entry, 
specify  fields  which  cannot  be  left  empty  or  blank,  specify  special  edit 
checks  on  the  data  (this  includes  having  the  DBMS  check  the  database  to 
see  if  a  value  is  already  present  in  the  database;  especially  useful  for 
codes).  In  addition,  the  prompts  and  error  messages  the  user  sees  can  be 
specified  as  well  as  special  on-line,  application  dependent,  help  files. 


IV  APPLICATIONS  PROGRAMS  UESICN 


_8 .  GENERAL  DESIGN  STANDARDS 

ii.l_._l.  Goals  and  Desires 

"We  build  systems-like  the  Wright  brothers  built  airplanes  -  build  the 
whole  thing,  push  it  off  a  cliff,  let  it  crash,  and  start  over  again." 
(REF  19  p  xi) 

The  goal  of  this  chapter  is  to  present  a  detailed  top-down  analysis 
and  design  of  a  reliable  set  of  applications  programs  which  will  access 
the  CADIS  database  and  fully  satisfy  the  present  and  future  operational 
requirements  of  AF1T/CI.  It  is  intended  that  the  set  of  documentation 
provided  by  this  chapter  wllL  make  it  easier  for  those  who  will  actually 
write  the  programs  to  understand  the  problems  of  AFIT/C1  as  clearly  as 
the  authors  presently  do  and  allow  them  to  translate  that  understanding 
into  a  usable,  maintainable  set  of  programs. 

By  relying  on  the  techniques  of  software  engineering,  it  is  more 
certain  chat  Che  actual  problems,  both  general  and  specific,  will  be 
understood  by  the  designer,  users  and  Implementors  before  any  code  Is 
ever  attempted.  This  will  insure  that  all  the  operational  needs  are  met 
and  the  users  will  have  a  system  which  works,  works  correctly,  and  is 
easy  to  use.  The  single  most  significant  advantage  of  using  these  tech¬ 
niques  is  that  the  system  will  be  easier  to  implement,  code  and  maintain 
at  a  much  reduced  cost. 
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“In  Che  1950's  and  1960's,  machine  costs  associated  with  systems 
development  exceeded  people  costs •••( however , J  in  todays  environment  peo¬ 
ple  costs  far  exceed  machine  costs...**.  (REF  18  p  29)  It  is  because  of 
this  statement  that  the  focus  of  this  section  Is  to  be  upon  the  func¬ 
tional  description  and  design  of  the  programs  and  not  an  actual  implemen¬ 
tation.  Because  a  decision  has  yet  to  be  made  as  tu  which  DBMS,  which 
hardware  and  what  .Higher  Order  programming  Language  (HOL)  will  be  used  to 
implement  this  project,  it  is  very  imporr *nt  that  a  well  thought  out 
design  be  agreed  upon  early.  It  is  important  to  note  that  “an  Important 
aspect  of  structured  design  includes  designing  on  a  logical  level  before 
continuing  to  the  specifics  of  a  particular  physical  solution.  A  logical 
design  is  easier  to  communicate  because  it  is  more  concise,  less  techni¬ 
cal  and  uses  graphics  [aids].  Once  the  users  have  agreed  to  the  logical 
requirements  of  the  system,  [it]  is  transferred .. .into  the  modules  of  the 
system. “  (REF  18  p  31) 

To  summarize,  our  goal  is  to  provide  a  top-down,  structured  design 
of  the  applications  programs  required  by  AFIT/CI.  By  so  doing,  it  is 
assured  that  they  will  meet  the  operational  specifications  and  will  be 
easy  to  implement  and  maintain. 

AFIT/CI  requirements  dictated  that  there  be  two  separate  software 
packages  designed.  While  the  general  design  for  both  systems  was  worked 
on  by  each  author,  the  specifics  and  details  were  basically  divided  along 
the  AFIT/CI  organizational  lines.  Capt.  Kicks  was  responsible  for  the 
Financial  System  (CIV)  and  Lt .  Colburn  handled  the  Personnel  System 
(C1M/R). 
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_8  .  Procedure 

The  general  procedure  to  be  followed  is  one  which  combines  aspects 
of  almost  all  of  the  procedural  and  graphic  techniques  currently  avail¬ 
able,  but  which  has  been  developed  and  extensively  used  by  Capt.  Ricks. 
The  only  assumption  which  must  be  made  for  this  technique  to  be  success¬ 
ful,  is  that  the  language  used  to  implements  it  must  support  a  “call" 
mechanism. 

This  procedure  centers  around  a  hierarchy  chart  and  two  written 
documents.  The  chart  is  a  modified  HIPO  chart  (REF  19  p  46)  which  incor¬ 
porates  elements  of  Structure  Charts  (REF  18  p  134)  as  well  as  Structured 
Analysis  and  Design  Techniques  (SADT)  charts.  The  two  documents  used  are 
a  functional  Description  (FD)  of  the  software  and  detailed,  module  by 
module  descriptions  of  the  components  shown  In  the  hierarchy  chart. 

Development  of  the  hierarchy  chart  1b  accomplished  in  two  distinct 
stages.  First  the  major  functions  or  operations  which  are  performed  are 
identified  and  listed  in  the  logical  order  of  performance.  Next,  these 
functions  are  refined  by  Incorporating  the  screen  displays,  commands  and 
other  operational  features  of  the  programs  as  specified  by  the  user. 
Once  the  sequence  of  events  and  software  .  teraction  have  been  agreed 
upon  by  the  designer  and  the  user,  the  chart  is  modified  to  reflect  the 
detailed  functions,  and  if  desired,  the  control  logic  which  the  applica¬ 
tions  programmer  will  actually  use  during  implementation. 

The  screen  displays  are  then  finalized  and  collected  together,  along 
with  appropriate  Inputs,  outputs  and  user  interactions.  This  is  docu¬ 
mented  and  becomes  essentially  a  pictorial  of  Just  huw  the  syste.ii  will 


act  and  look  when  the  user  gets  on  the  terminal.  This  narrative  is  the 
Functional  Description  (FD)  of  the  software  and  will  become  a  users 
manual  once  the  system  Is  completed.  It  is  against  this  document  that 
the  programmer  must  verify  his  formats  and  responses  during  the  coding 
and  testing  of  the  system. 

The  third  element,  and  perhaps  the  most  important,  is  the  detailed 
description  of  each  function  represented  o.i  the  hierarchy  chart.  Uhen 
the  functions  have  been  broken  down  sufficiently,  according  to  structured 
analysis  principles  (REF  18  &  19),  they  will  in  essence  represent  the 
actual  modules  or  subprograms  which  must  be  coded. 

The  level  of  documentation  includes  the  inputs  and  outputs  of  each 
module  as  well  as  a  structured  english  (REF  18  p  321)  description  of  the 
procedures  needed  to  transform  the  specified  input  to  the  desired  out~ 
put.  By  doing  this  for  each  module,  the  programmer  can  transform  this 
set  of  specifications  directly  into  the  desired  HOL  statements  required 
for  implementation. 

It  is  assumed  and  encouraged  that  the  tenets  of  structured  program¬ 
ming  (coding)  be  followed  strictly  and  zealously  to  insure  that  the 
design  is  accurately  reflected  in  the  actual  code. 

Each  of  the  above  documents  are  listed  in  appendix  111.  The  hierar¬ 
chy  charts  are  appendix  I11B  &  IIIE,  the  Functional  Descriptions  are 
appendix  IIIC  &  IIIF  and  the  modules  descriptions  are  appendix  111D  & 
1 IIC.  Also  listed  in  appendix  III  a»e  the  new  relations  for  the  database 
which  were  developed  after  further,  in  depth,  analysis  of  the  AFir/CI 
operations.  These  relations  must  be  added,  or  modified  in  some  cases,  in 


order  for  Che  software  to  produce  the  desired  results. 

The  above  procedure  for  the  design  of  applications  software  is  not 
significantly  different,  in  principle,  from  those  advocated  by  current 
software  engineering  literature  and  practices.  What  has  been  done  how¬ 
ever,  is  to  combine  those  aspects  and  details  which  work,  best  and  ignore 
those  which  the  author  feels  constrain  or  limit  the  productiveness  of 
software  designers.  This  process  has  been  employed  by  the  author  on  many 
systems  at  several  locations  and  under  differing  situations  with  very 
good  success. 

j).1.3^  Documentation 

A  specific  format  has  been  adopted  to  document  the  modules  within 
the  hierarchy  charts.  Each  module  is  listed  by  number  and  a  descriptive 
name,  along  with  what  it  does  (function)  and  Its  input  and  output.  A 
variable  is  considered  an  input  or  output  rased  upon  its  value  and  its 
use  within  the  module.  For  example,  a  parameter  whose  value  is  set  or 
reset  within  the  module  is  considered  an  output  while  one  which  is  passed 
in  for  information  or  control  is  an  input. 

Probably  tne  most  important  portion  of  the  documentation  is  the 
description  of  the  procedure  or  workings  of  the  modules.  K  highly  struc¬ 
tured  engllsh  (REF  18  &  19)  description  is  used  to  show  which  and  where 
each  parameter  is  set,  what  subroutines  are  called,  an*  the  governing 
logic  at  each  level. 
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In  several  modules  Che  reference  co  "get  input"  and  "get  line"  is 
used.  "Get  Input”  is  used  whenever  a  single  value  is  to  be  entered  (e.g. 
from  a  menu)  and  "get  line"  is  used  when  an  entire  line  of  values  (e.g.  a 
line  from  an  update  display)  is  entered.  A  basic  assumption  is  that  when 
the  line  is  provided  to  the  module  all  spurious  characters  are  stripped 
away  and  the  only  thing  left  are  the  input  fields  with  possibly  a  delim¬ 
iter  character  between  them.  The  actual  mechanics  must  be  left  to  the 
programmers  and  the  specific  language  used. 

Another  function  which  is  referred  to  in  general  terms  is  that  of 
"edit  input".  Each  field  that  is  changed  by  the  user  must  be  checked  for 
validity  and  correctness  of  format.  These  details  were  also  left  for  the 
programmers  because  it  was  not  known  ex.  ~ly  what  all  the  criteria  for 
each  field  were.  Any  error  checking  should  notify  the  user  Immediately 
(at  the  bottom  of  the  screen)  and  allow  him  to  correct  his  mistakes.  Of 
primary  consideration  is  the  line  numbers  on  the  update  programs.  The 
easiest  way  of  displaying  these  lines  is  to  build  them  and  place  them  in 
an  array  within  the  program.  When  they  are  displayed,  the  line  number 
corresponds  co  their  location  within  the  array.  If  the  line  numbers  are 
changed  or  messed  up  in  any  way,  the  program  will  not  be  able  to  guaran¬ 
tee  che  accuracy  of  the  results. 

In  some  of  the  modules  a  variable  called  "ifun"  is  used.  This  vari¬ 
able  represents  the  value  of  the  function  or  command  (FUN/CMD)  column  on 
the  update  displays  as  input  by  the  user.  If  need  be  Its  value  will  be 
assigned  to  the  master  control  parameter  FUNCTION. 


The  software  requirements  of  AFIT/CI  were  gathered  by  means  of  a 
simple  questionnaire  (Appendix  IIIA).  It  was  developed  jointly  by  the 
authors  and  given  to  the  data  automation  representative  of  AFIT/CI  to 
complete.  Responses  to  this  form,  in  various  forms  and  formats,  provided 
the  basic  groundwork  for  both  the  data  requirements  and  the  performance 
specifications  and  criteria  for  the  software.  This  initiated  a  continu¬ 
ing  process  of  question  and  answer  sessions  with  the  users  which  cul¬ 
minated  in  the  software  design  presented  here. 


8.1.5.  Design  Approach 


The  approach  to  the  design  of  the  AFIT/CIV  software  was  as  follows: 


(1)  Interview  the  program  manager  representatives  from  AFIT/CI. 

(2)  Formulate  the  initial  design  requirements  based  on  interviews  and 
the  questionnaire  (Appendix  IILA). 

(3)  Develop  the  initial,  high  level,  top-down  interface  design. 

(4)  Review  the  initial  design  with  the  program  manager  representatives. 

(5)  Re-evaluate  the  design  and  make  appropriate  changes  requested  by  the 
user. 

(6)  Consolidate  all  notes  and  rough  drafts  and  prepare  the  results  for 
final  presentation  and  documentation. 


jl.  Uf^.  Kequlred  Hardware 

In  addition  to  the  central  computer  system  which  uses  the  DHMS,  the 
only  additional  hardware  required  to  use  the  software,  as  presented  here, 
are  terminals.  The  programs  have  been  designed  to  use  the  facilities  of 
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a  CRT  which  uses  direct  cursor  addressing  and  has  the  ability  to  produce 
protected  and  unprotected  fields.  All  displays  and  programs  operate  on 
this  assumption  and  were  designed  to  be  used  by  any  user  simply  and 
easily.  This  will  simplify  data  entry  and  manipulation,  reduce  wasted 
time  due  to  errors  and  confusion,  and  provide  a  system  which  is  more 
readily  accepted  by  the  user. 
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8.2.  AFIT/CIM/R  SOFTWARE  DESIGN 


(This  software  design  was  authored  by  Lt.  Robert  Colburn) 

Todays  Air  Force  requires  a  seemingly  ever  increasing  supply  of  well 
educated  doctors,  engineers  and  scientists.  Much  of  the  responsibility 
for  fulfilling  these  needs  fall  upon  the  AFIT  Civilian  Institution  Pro¬ 
grams  directorate*. 

AFIT/CI  is  responsible  for  managing  the  civilian  institution 
academic  programs,  medical  training.  Education  With  Industry  (EWI)  and 
the  MinuteMan  Education  Program  (MMEP).  These  programs,  plus  many  oth¬ 
ers,  and  their  students  are  all  managed  by  either  CIR  (regular  programs) 
or  CIM  (medical  programs). 

Approximately  5000  widely  dispersed  students  (geographically),  in 
approximately  300  universities  and  institutions  are  managed  by  AFIT/CI. 
This  is  accomplished  by  15  program  manager  teams  directly  interfacing 
with  the  students,  the  civilian  Institution  in  which  they  are  enrolled 
and  the  Air  Force,  all  on  a  daily  basis.  Presently,  all  record  keeping 
and  data  retrieval  is  carried  out  using  file  folders  and  manual  methods. 
This  inefficient  and  Inadequate  mode  of  operation  is  severly  handicapping 
the  ability  of  the  program  managers  to  provide  the  required  guidance  to 
their  students  and  is  overloading  the  current  manpower  level.  AFIT/CI 
has  recognized  this  fact  for  a  long  time  as  being  unsatisfactory  and 
detrimental  in  terms  of  meeting  dally  operational  requirements.  Given 
the  increased  emphasis  on  engineers  and  scientists  within  the  Air  Force 
and  the  corresponding  Increase  in  enrollments  in  civilian  Itutlons  to 
meet  this  goal,  the  current  situation  will  only  become  worse. 


In  order  Co  properly  cope  with  che  present  and  future  operational 
overload,  AFIT/CIM/R  has  chosen  to  automate  Its  information  processing 
system.  It  Is  within  the  context  of  this  background  and  a  desire  to 
solve  and  enhance  operational  capability,  that  the  design  of  a  special 
set  of  applications  software  has  been  undertaken. 

It  1 s  a  recognized  fact  that  AFIT/CIM/R  has  an  information  problem 
that  Is  impacting  their  ability  to  handle  the  civilian  institution  pro¬ 
grams.  The  underlying  assumption  of  this  thesis  is  that  a  set  of  user 
friendly  applications  programs  specifically  tailored  to  meet  their  needs 
and  acting  as  an  interface  to  the  CADIS  database  will  alleviate  both 
current  and  projected  workload  and  information  problems. 

While  this  software  will  go  a  long  way  toward  helping  AFIT/CIM/R, 
such  a  system  is  not  a  panacea  for  all  their  problems.  However,  in  terms 
of  efficiently  storing,  organizing  and  quickly  processing  their  large 
amounts  of  data,  this  approach  has  repeatedly  proven  effective  throughout 
the  commercial,  federal  and  academic  arenas. 

J1.2^ 1 .  Ceneral  User  Requirements 

Interviews  with  program  manager  representatives  from  AFIT/CIM/R 
indicated  that  there  are  four  primary  areas  which  they  use  frequently  and 
urgently  need  automated.  These  areas  are: 

(1)  Student  Biographical  Data 

(2)  Education  Plan  data 

(3)  Memorandums  For  The  Record 
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(A)  Suspense  Dates  and  Actions 


The  relations  to  support  these  areas  are  already  present  in  the 
CADIS  database  with  the  exception  of  the  suspense  data.  This  may  be 
found  in  appendix  IIIH.  Because  the  data  management  needs  of  the  two 
divisions  ,  CIM  and  CIR,  are  so  similar,  only  one  logical  data  view  has 
been  provided  for  both. 
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8.3_.  AFIT/CIV  SOFTWARE  DESIGN 

(This  software  design  was  authored  by  Capt.  Jeffrey  Ricks) 


The  Accounting/Data  Control  Division  of  the  Civilian  Institution 
Programs  Directorate  (AFIT/CIV)  is  responsible  for  maintaining  all  the 
financial  matters  pertaining  to  the  thousands  of  geographically  dispersed 
students  enrolled  in  civilian  universities  for  the  purpose  of  obtaining 
an  AF1T  sponsored  degree.  AFIT/CIV  currently  handles  financial  data  and 
is  responsible  (fiscally)  for  approximately  5000  students  enrolled  in 
some  300  universities,  in  various  educational  programs,  across  the  coun¬ 
try.  In  the  performance  of  their  duties,  they  have  no  subordinate  level 
of  administration  and  must  be  in  contact  w^th  each  student  at  each 
university  throughout  the  year.  Currently  this  task  is  being  accom¬ 
plished  with  manual  filing  systems  and  approximately  eight  office  person- 


The  major  duties  which  must  be  accounted  for  include: 

(1)  Payment  of  tuition  and  fees  for  each  student.  Such  payments  may  be 
made  either  directly  to  the  student  or  to  the  university,  depending 
upon  the  school  and  specific  program,  up  to  four  times  per  year. 

(2)  Reimbursements  for  approximately  1500  students  for  authorized 
expenses  incurred;  up  to  four  times  per  year. 

(3)  Preparation  and  continual  maintenance  of  individual  financial 
records  on  tuition  and  all  fees  for  approximately  3000  students  and 
personal  reimbursements  for  approximately  1500  students. 

(4)  Generation  of  routine  statistical  and  audit  data  on  students,  pay¬ 
ments  and  institutions  for  AFIT  plus  special  requests  from  HQ/USAF , 
AFMPC  and  offices  throughout  000. 

(5)  Tuition  and  fee  charges  for  approximately  300  universities.  This 
translates  into  a  wide  variety  of  tuition  rates  (resident  vs  non¬ 
resident),  fee  charges  (lab,  parking,  etc),  academic  term  breakdowns 
(quarter,  semester,  etc)  and  billing  procedures. 


Maintaining  financial  data  plus  the  tracking  of  both  students  and 
universities,  spread  all  across  the  country,  renders  the  verification  of 
charges  and  the  posting  and  payment  of  bills  by  manual  means  virtually 
impossible.  Additionally,  no  automated  means  for  the  payment  of  invoices 
and  reimbursements,  bookkeeping,  as  well  as  performing  cost  tracking  and 
forecasting,  budget  analysis,  statistical  analysis  and  man  year  load 
analysis  currently  exists  within  AFIT.  The  result  is  that  the  current 
workload  has  already  surpassed  the  authorized  manpower  and  the  quality 
control  and  audit  capabilities  for  a  budget  which  exceeds  4.5M  annually 
is  severely  threatened.  Additionally,  AF1T/C1V  is  frequently  several 
weeks  or  sometimes  months  behind  in  the  prompt  payment  of  bills. 

Among  the  major  problems  which  currently  exist  are  no  forecasting 
capability  of  any  type  in  any  area,  inability  to  maintain  historical  stu¬ 
dent  and  Institution  data,  no  direct  (automated)  access  to  files  and 
information,  inability  to  use  and  maintain  over  75Z  of  the  data  items 
essential  for  financial  program  management,  no  timely  reporting  in  the 
required  formats,  and  no  automatic  verification  of  data. 

8^. 3 . K  General  User  Requirements 

The  AF1T/CIV  directorate  must  have  the  ability  to  automatically 
update  and  review  the  Invoices  and  vouchers  for  each  Institution.  They 
must  be  able  to  record  the  amount  due,  the  date  the  invoice  was  received 
and  match  it  with  a  specific  AF  voucher  for  payment  of  the  amount  due. 
Additionally,  they  also  must  be  able  to  cross  reference  this  invoice  to 
the  students  for  which  it  covers. 
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Each  studenc  must  have  a  record  kept  which  shows  a  detailed  break¬ 
down  of  the  expenses  he  has  incurred,  the  amount,  the  date  and  when  they 
were  paid  (cross  reference  to  the  school  invoices  &  vouchers).  The  gen¬ 
eral  biographical  data  will  be  handled  through  the  program  managers  from 
APIT/CIM.  Additionally,  there  must  be  a  means  of  generating  a  payment 
list  which  can  be  sent  to  the  local  finance  office  notifying  them  to 
issue  checks  for  the  listed  students  for  the  specified  amount. 

AT  each  school  there  are  Individual  contacts  with  which  the  office 
personnel  routinely  deal.  An  automated  means  of  listing  and  updating 
each  POC,  their  current  phone  number  and  address  must  be  provided. 

In  order  to  make  the  general  programs  work  correctly,  the  database 
must  keep  track  of  the  costs  of  all  the  various  programs,  schools  and 
their  facets.  Each  school  has  different  charges  for  tuition,  both  gradu¬ 
ate  and  undergraduate,  as  well  as  the  many  fees  which  may  be  charged.  By 
combining  the  current  student  and  school  data  with  these  figures,  the 
required  cost  forecasting  will  be  able  to  be  accomplished. 
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FROM:  AFIT/NR 

SUBJECT:  Consolidated  A^LT  Database 


16  July  1982 


TO:  AFIT/CCE  DA  PA  DP  RM  ACD  LD 

ED  RR  EN  LS  DE  Cl  CAE 

1.  On  3  July  1982  the  Computer  Configuration  Board  (CCB)  met  to  discuss 
the  need  for  and  timeliness  of  various  solutions  to  the  administrative 
problems  continually  faced  by  AFIT.  After  considering  several  presentations 
on  both  past  efforts  and  current  projects,  including  current  thesis  projects, 
the  CCB  decided  that  in  order  to  cope  with  the  ever  increasing  student  load 
and  the  associated  administration  thereof,  a  database  management  system  (DBMS) 
could  support  AFIT  and  should  be  implemented  as  a  long  range  project.  The 
intention  of  such  DBMS  would  be  to  consolidate  all  the  information  required  by 
the  departments  within  AFIT  and  provide  simple  and  easy  access  to  all  authorizei 
personnel . 

2.  The  first  step  in  such  a  project  is  to  gather  all  the  information  which 
each  department  requires  to  perform  its  duties  and  derive  a  database  structure 
which  will  adequately  serve  all  the  Intended  users.  Two  AF1T/EN  students, 

Capt  Kicks  and  Lt  Colburn,  have  volunteered  to  gather  the  needed  information  as 
a  part  of  their  thesis  investigation.  Capt  Ricks  and  Lt  Colburn  will  be 
gathering  various  kinds  of  data,  performing  analyses  and  making  specific 
recommendations  to  the  CCB  concerning  a  consolidated  AFIT  DBMS.  Their  first 
task  is  to  contact  each  of  the  departments  within  AFIT  in  order  to  determine 
their  information  and  report  requirements  and,  if  possible,  the  specific  data 
elements  they  use. 

3.  It  is  requested  that  each  addressee  designate  someone  to  meet  with  and 
provide  Capt  Ricks  and  Lt  Colburn  the  data  they  require  so  significant  progress 
may  be  made  toward  defining  our  information  requirements.  They  will  be 
contacting  each  addressee  on  an  individual  basis  to  arrange  meetings. 

4.  If  you  have  any  questions,  please  contact  Major  Lillie,  extension  32024. 


SIGNED 

L.  E.  WOLAVER 

Dean  for  Research  and 

Professional  Development 


Appendix  IA 


WORK  SHEET 


OFFICE  SYMBOL:  CAPT.  RICKS 

LT.  COLBURN 

POINT  OF  CONTACT:  EXT.  52194 

PROPOSED  INTECRATED  AFIT  DATABASE  RECORDS  AND  ATTRIBUTES 
(NOTE:  EN's  Database) 

STUDENT  DATA:  SSSN,  Name,  Rank,  PAFSC,  Ed  Code,  DOR,  DOC,  DOB,  POB, 
I’hone,  Duty  Phone,  Address,  Emer  Address,  Religion,  Aero  Rating,  Losing 
Command,  Military  Spouse,  Years  of  Service,  Last  Organization,  Position 
Title,  Duration 

BOX  NUM:  BOX  NUM 

SECTION:  SECTION  NUM,  Grad  Date,  Enter  LDate,  Num  in  Section,  LDRSSN 
THESIS  DATA:  THESIS  NUM,  Title,  Sponsor,  Location,  Classification 
CRADES:  SSSN,  Course  Num,  Quarter,  Grade 

FACULTY  DATA:  FSSN,  Name,  Rank,  Phone,  Home  Phone,  Room,  Office  Symbol, 
Department,  Job  Title,  Begin  Date,  End  Date,  Address,  DOB,  Spouse,  SDOB, 
Marital  Status,  Num  of  Dependents,  Dependent  Names,  Service,  Religion, 
Photo  Date 

AWARDS:  FSSN,  Award,  Award  Date 
PUBLICATIONS:  PUBTITLE,  FSSN 

TDY:  TDYDEST,  FSSN,  Begin  Date,  End  Date,  Tripcost 

COLLECES:  FSSN,  College,  Begin  Date,  End  Date 

DEGREES:  FSSN,  Degree,  Degree,  College,  Year 

PUBLICATION  DATA:  PUBTITLE,  Date,  Topic,  Source,  SSSNAUT 

COURSE  DATA:  COURSE  NUM,  Credhrs,  Lechrs,  Labhrs,  Description,  Outline, 
Sizelmt  Sizelmt 

TITLE:  COURSE  NUM,  Title 

PREREQ:  COURSE  NUM,  Prereq  Num 

BOOKS:  BOOK  TITLE,  Author,  Publisher,  Num  Avail,  Price 
BOOK  ORDERS:  AUTHO>  Rook  "r  :e,  Order  Num,  Num  Ordered 
ORDERS:  ORDER  NUM,  Order  Date,  Due  Date 
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COURSE  BOOKS:  Course  Num,  Author,  Title 

OFFERINGS:  Course  Num,  Quarter 

DATES:  Quarter,  Date 

QUARTER:  QUARTER 

ROOMS:  ROOM,  Bldg,  Num  Allowed 

SCHEDULE:  DATE,  Time,  Room,  Course  Num 

PRESENTATIONS:  FSSN,  Date,  Presentation  Title,  Location,  Org 

COMMITTEES:  FSSN,  Committee 

STUDENT  AWARDS:  SSSN,  Award,  Award  Date 

STUDENT  SCHOOL:  SSSN,  College,  Course  Num,  Crade 

STUDENT  DEGREES:  SSSN,  Degree,  College,  Year 

INSTRUCTOR:  FSSN,  Course  Num,  Quarter 


ATTRIBUTE  EXPLANATION 

RECORD 

ATTRIBUTE 

EXPLANATION 

SECTION 

LDRSSN 

Section  leader's  SSN 

THESIS 

LOCATION 

Sponsor's  location  DATA 

PUBLICATION 

SSSNAUT 

Student  coauthor's  SSN 

DATA 

PRESENTATION 

ORGANIZATION 

Organization  the 

given  to 

presentation 

FACULTY 

DATA 

FSSN 

Faculty  members  SSN 

FACULTY 

DATA 

S  DOB 

Spouse's  date  of  birth 

COURSE 

DATA 

SIZELMT 

Maximum  number  of 

are  permitted  to  enroll 

students 
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WORK  SHEET 


OFFICE  SYMBOL: 

POINT  OF  CONTACT: 

VERSION  1 

REGISTRAR'S  DATA  BASE 

STUDENT-RECORD:  SSAN,  CLASS  (e.g.  82-D),  PROCRAM  (e.g.  GCS),  Student-code 
(e.g.  RS-resident,  Cl-civilian  institution),  last-name,  first-name, 
middle-initial,  riame-ps  (e.g.  jr.,  sr.),  student-title  (e.g.  2LT,  MR.), 
rank-type  (e.g.  CS,0),  rank-level  (e.g.  12,  1),  date-of-birth, 

AFIT_school_code  (e.g.  1-EN,  2-LS),  manning-code  (e.g.  1-AF  officer,  reg¬ 
ular),  sex,  last-majcom,  output-ma jcom ,  aero-rating  (e.g.  1-pilot), 
ethnic-group  (e.g.  1-white),  prior-degree  (e.g.  n4iyy),  undergrad-GPA, 
marital-status  (e.g.  l»single) ,  primary-specialty-code,  entry-date  (begin 
AFIT),  graduation-date,  departure-date,  degree-granted  (e.g.  2-M.S.), 

prior-AFIT  (no.  of  mths),  education-code,  folder-location  (e.g.  1-RR, 
3-CI),  departure-reason  (e.g.  1-graduated  with  degree),  transfers  (no.  of 
times  transfered  programs),  trans-in-date ,  trans-out-date,  grade-  point- 
average,  CRE-verbal,  GRE-quan,  GRE-total,  GRE-advanced ,  CMAT-verb,  CMAT- 
quan,  GMAT-total 

STUDF. NT-RECORD  FIELDS  UNIQUE  TO  RESIDENT  STUDENT  RECORDS  (RS):  resident, 
status  (1-full  time),  student-number,  student-box  number,  adviser 

STUDENT -RECORD  FIELDS  UNIQUE  TO  CIVILIAN  INSTITUTIONS  RECORDS  (Cl): 
civll-inst,  university,  academic  standing  (e.g.  2-probation),  suspense, 
speciality-code,  legal-residence,  thesis-dis-approval  (e.g.  A-approved), 
medical-accession-source ,  previous-raedica 1-degree ,  presen t-raed leal- 
program,  medical  tours,  MEDCAT-exam-scores 

STUDENT-RECORD  FIELDS  UNIQUE  TO  TRANSFER  RECORDS  (TR):  transfer,  old-<-info 
(info  unique  to  old  record),  old-code  (previous  student  code) 
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WORK  SHEET 


OFFICE  SYMBOL: 

POINT  OF  CONTACT: 

VERSION  2 

REGISTRAR'S  DATA  BASE 
STUDENT  RECORDS  SYSTEM 

COURSE  TERM  FILE  DATA:  course  section  number,  activity  type  (e.g. 
LEC-lecture) ,  term  (e.g.  821-1982  winter),  course  section  title,  section 
cntrl  (special  processing,  e.g.  I-informal  credit  activity),  minimum 
credit  (min.  no.  of  credit  hours  for  a  course),  maximum  credit,  variable 
credit  (e.g.  3-credit  to  be  arranged),  special  grading  (e.g.  C*credit/no 
credit  only),  course  level  (e.g.  G-graduate  credit),  course-college, 
course-college  &  dept,  course-number,  course  section,  course  status  (e.g. 
O-open),  wait  li6t  code  (e.g.  N-no  wait  list),  resection  code,  room  size 
(e.g.  5-space  for  over  50),  room  requirement  (e.g.  C-classified  room), 
schedule  print  (e.g.  N-do  not  print  on  published  schedule),  schedule 
notes  1  (e.g.  L-taught  on  an  independent  study  basis),  schedule  notes  2, 
schedule  notes  3,  crs  section  (e.g.  S=special  offering),  crs  start  date, 
crs  end  date,  exam  schedule  code  (e.g.  Y=yes,  schedule  exam),  term  type 
(e.g.  l*winter),  proj  enrollment,  enrollment  limit,  minimum  enroll¬ 
ment,  enrolled  tally,  demand  tally,  drop  tally,  wait  list  tally,  non-reg 
tally  (students  enrolled  with  out  formal  regristration) ,  add  tally,  audit 
tally,  1st  meet  days  (e.g.  M-Monday) ,  1st  meet  starts  (e.g.  0850-8:50 

AM),  1st  meet  stops,  1st  meet  bldg  (e.g.  640-bldg  640),  1st  meet  room, 
2nd  meet  days,  2nd  meet  starts,  2nd  meet  stops,  2nd  meeting  bldg,  2nd 
meeting  room,  3rd  meet  days,  3rd  meet  starts,  3rd  meet  stops,  3rd  meet 
bldg,  3rd  meet  room,  1st  inst  ssno  (1st  instructors  ssn),  1st  inst  load 
(Xof  course  credit  1st  inst  is  credited  for),  2nd  inst  ssno,  2nd  inst 
load,  3rd  inst  ssno,  3rd  inst  load,  4th  inst  ssno,  4th  inst  load,  5th 
inst  ssno,  5th  inst  load,  6th  inst  ssno,  6th  inst  load,  1st  inst  name, 
group  contact  hours  (total  no.  of  hrs  per  week  faculty  members  meet  with 
students  as  a  group),  indiv  contact  hours  (total  no.  of  hrs  per  week  ea. 
student  meets  with  the  faculty  member  on  an  individualized  basis),  dept 
of  record  (e.g.  EENG-electr ical  engineering),  ctf  maint.  date  (date  of 
last  maintenance  on  ea.  record) 

STUDENT  BIOGRAPHIC  AND  DEM0CRAPHIC  DATA  (STUDENT  KEY  FILE  ITEMS):  special 
name  flag  (indicates  special  spelling  or  punctuation  of  student's  name), 
student  identification  (student's  ssn),  re-admit  term  (indicates  term  a 
withdrawn  student  wishes  to  return),  country,  into  release  flag  (e.g. 
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N-do  not  release  any  info),  grade  mail  flag  (where  grades  are  to  be 
mailed  to,  e.g.  P-permanent  address),  partial  rec  flag  (e.g.  N-no,  record 
is  complete),  advisor  ID  no.,  academic  elig  (e.g.  Y-yes,  automatically 
register),  cumulative  earned  ho  (cum.  hrs.  earned),  cumulative  CPA,  calc 
required  term,  current  college  (e.g.  EN-school  of  engineering),  current 
classification  (e.g.  CM-  master's  candidate),  curent  degree  (degree  pro¬ 
gram  student  is  currently  enrolled  in,  e.g.  MS-raast  of  science),  current 
major  (e.g.  MATH-mathematics) ,  degree  expected  term  (expected  graduation 
term),  deg  check  out  term  (expected  degree  requirements  completion  term), 
deg  ckout  status  (e.g.  1-filed  graduation  plans),  administrative  hold 
(e.g.  H-records  being  held) 

ADMISSIONS  DATA:  entry  date,  entry  term,  adm  college,  adm  classification, 
adm  degree,  adm  major,  prev  coll  FICE  code,  prev  college  CPA,  admission 
action  (e.g.  A-application  process  complete),  admission  type  (e.g. 
CRD-entering  with  undergrad  degree),  prev  academic  level  (e.g. 
BD-baccalaureate  degree),  entrance  exam  1  (e.g.  GMAT-GMAT  total),  test 
score  1,  entrance  exam  2,  test  score  2,  entrance  exam  3,  test  score  3, 
entrance  exam  4,  test  score  4,  entrance  exam  5,  test  score  5,  entrance 
exam  6,  test  score  6,  entrance  exam  7,  test  score  7,  entrance  exam  8, 
test  score  8,  skf  maint  date  (date  record  last  maintained) 

STUDENT  TERM  FILE  ATTRIBUTES  AND  ACADEMIC  PROCRAM  DATA:  dean's  list  (e.g. 
*Y-  on  dean's  list),  academic  action  (e.g.  *PW-placed  on  warning),  with¬ 
draw  code  (e.g.  A-academic  difficulty),  withdraw  date,  college,  classifi¬ 
cation,  primary  major  1,  primary  major  2,  primary  major  3,  primary  minor 
1,  primary  minor  2,  secondary  degree,  secondary  major,  grad  code  (e.g. 
F-flrst  degree  program  complete),  mail  building  (e.g.  EN-bldg  b40),  box 
number,  reg  type,  prog  notice  flag  (e.g.  2-student's  program  has  been 
revised,  a  notice  needs  to  be  issued),  grade  rpt  flag  (e.g.  3-grade 
report  received),  term,  social  security  no.,  last  calc  date  (date  of  last 
system  calculated  grade),  stf  maint  date,  TRF  earned  hours  (transfer 
credit  awarded),  curr  earned  hrs,  curr  qual  hrs  (does  not  include 
credit/no  credit  hrs),  curr  qual  pts  (current  grade  pts  awarded  for  suc¬ 
cessful  completion  of  academic  work),  cum  earned  hrs,  cum  qual  hrs,  cum 
qual  pts,  higher  ed  qual  hours,  higher  ed  qual  points 

REGISTRATION  DATA  (SPE-I):  SPE  crs  number,  SPE  status  (e.g.  E-enrolled), 
grade  type  (e.g.  CN-credit/no  credit),  official  grade  (e.g. 
A-excellent-4 .0) ,  prior  grade  (official  grade  before  any  grade  change), 
registered  hours,  earned  hrs  flag,  quality  points,  drop  reason,  quality 
hrs  flag,  career  pointer  (e.g.  C-award  graduate  credit  and  distribute  to 
graduate  career),  regristration  level  (e.g.  C-graduate),  session,  SPE 
maint  date  (date  of  last  change  to  SPE),  course-college,  course-col  & 
dept,  course-number,  course-section 
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ADMINISTRATIVE  TERM  ACTIVITY  DATA  (SPE-II):  SPE  type,  init  career  no 
(e.g.  2»graduate),  init  earned  hours,  init  quality  hours,  init  quality 
points,  init  higher  ed  qhrs,  init  higher  ed  qpts,  SPE2  init  maint  date, 
TRF  activity  no,  TRF  school  code  (FICE  code  ror  transferring  inst.)>  TRF 
hours  earned,  TRF  quality  hours,  TRF  quality  points,  TRF  begin  date  (date 
transfer  work  began),  TRF  end  date,  TRF  term  applied  (term  to  which 
transfer  credit  is  to  be  applied),  SPE2  TRF  maint  date,  deg  activity  no, 
deg  school  code  (FICE  code  for  school  awarding  the  degree),  deg  date,  deg 
major  l,  deg  major  2,  deg  major  3,  deg  minor  1,  deg  minor  2,  deg  honors 
(e.g.  M«magna  cum  laude)  SPE2  deg  maint  date 
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Description  of  the  Relations  for  the  Consolidated  AFIT  Database 


1.  ACADEMIC_TITLES 

This  relation  contains  a  list  of  the  Academic  titles  a 
faculty  member  may  hold.  F.ach  title  is  indexed  by  a 
unique  code  which  will  allow  other  relations  to  key  to 
the  full  title.  Each  entry  has  a  maximum  size  of  35 
characters. 


2.  AFITjCALENDAR 

This  relation  allows  users  to  maintain  a  list  of  the 
AFIT  activities  which  occur  throughout  the  year.  Along 
with  a  description  of  each  event  is  a  special  indicator 
to  designate  whether  or  not  it  is  an  activity  which 
Involves  the  commandant.  Appropriate  remarks  may  be 
Included  along  with  any  POC  (Point  of  Contact).  Each 
entry  has  a  maximum  length  of  128  characters. 


3.  AFIT_COURSES 

This  relation  contains  information  pertaining  to  all 
courses  listed  in  the  AFIT  catalog.  The  course  number 
(i.e.  F.E646A)  will  allow  users  to  key  into  this  infor¬ 
mation  from  other  relations.  Each  entry  has  a  maximum 
length  of  145  characters. 


4.  AFSC 

This  relation  contains  a  list  of  the  six  character  Air 
Force  Specialty  Codes  (AFSC)  and  their  descriptions. 
This  medical  code  is  strictly  used  by  AFIT/C1.  Each 
entry  has  a  maximum  length  of  56  characters. 


5.  ALLOW ANCE_PAYMEHTS 

This  relation  contains  data  on  the  different  allowances 
which  have  been  paid  to  a  non  Cl  student.  Each  tine  a 
payment  is  made,  the  students  SSAN  will  be  entered 
along  with  the  type  of  payment  (books,  thesis,  etc)  and 
the  date  on  which  the  transaction  occurred.  Allowance 
type  is  a  two  letter  code  whose  description  is  found  in 
the  ALLOW ANCE/PAYMENT_TY PE S  relation.  F.ach  entry  has  a 
maximum  length  of  25  characters. 

ft.  ALLOWANCE/ PA YMENT_TYPES 

This  relation  contains  the  two  letter  Allowance_Types 
and  their  descriptions.  F.ach  entry  has  a  maximum 
length  of  52  characters. 
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7.  AUDIO_VIS 

This  relation  contains  data  on  the  audio/visual 
resources  which  may  be  checked  out,  such  as  movies  and 
tapes,  for  which  the  AFIT  library  is  responsible.  Each 
entry  has  a  maximum  length  of  139  ciiaracters. 


8.  AWARDS 

This  relation  contains  data  concerning  the  various 
types  of  awards  which  have  been  presented  to  the  staff. 
They  include  official  awards  and  decorations,  civilian 
and  academic  awards  as  well  as  resident  school  awards 
such  as  outstanding  instructor.  Each  entry  has  a  max¬ 
imum  length  of  45  characters. 

9.  BlNDINCS 

This  relation  contains  the  special  data  required  by  the 
library  for  tracking  periodicals  that  are  bound 
together.  Each  entry  has  a  maximum  length  of  46  char¬ 
acters  . 


10.  BOOKS 

This  relation  contains  data  for  the  bookstore  and 
faculty  and  concerns  the  current  availability  of  text¬ 
books.  Each  entry  has  a  maximum  length  of  124  charac¬ 
ters. 


11.  B00K_0RDERS 

This  relation  contains  information  on  the  status  of  the 
orders  placed  by  the  bookstore  for  textbooks.  Each 
entry  has  a  maximum  length  of  105  characters. 


12.  BOXES 

This  relation  maintains  data  on  the  availability  and 
disposition  of  student  mailboxes.  When  a  box  has  been 
assigned,  the  students  SSAN  will  be  placed  with  the  box 
number;  when  unasslgned,  the  SSAN  for  a  box  will  be 
empty  (blank).  This  procedure  will  allow  administra¬ 
tive  personnel  to  not  only  assign  multiple  students  to 
a  box,  but  obtain  a  list  of  boxes  with  no  students. 
Each  entry  has  a  maximum  length  of  13  characters. 


13.  CHECKOUTS 

This  relation  contains  the  data  essential  for  checking 
out  material  from  the  library.  Id_No  is  the  SSAN,  or 
other  unique  identifier  in  the  case  of  foreign  stu¬ 
dents,  of  the  student  or  staff  member  checking  out  the 
book.  This  will  allow  indexing  into  the  STUDENT, 
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STAFF,  MON_STUDENT,  SIIOKT_STUDENTS  and  LIBRARY_BOOKS 
relations.  Each  entry  has  a  maximum  length  of  65  char¬ 
acters  . 

14.  CIJJATA 

This  relation  contains  data  peculiar  to  those  students 
enrolled  in  civilian  institutions.  Because  of  the 
requirements  dictated  by  the  AFIT/CI  mission,  certain 
additional  data  must  be  maintained  beyond  the  basic 
data  found  in  the  STUDENTS  relation.  The  data  in  STU¬ 
DENTS  and  CI_DATA  are  logically  linked  by  the  students 
SSAN.  Each  entry  has  a  maximum  length  of  188  charac¬ 
ters  . 


15.  CI_PROCRAMS 

This  relation  contains  all  AFIT/CI  programs  and  their 
descriptions  which  are  in  the  AFIT/CI  course  catalog. 
Each  program  is  represented  by  a  unique  code  which  is 
the  same  as  the  Ed_Code  used  by  the  resident  school . 
Each  entry  has  a  maximum  length  of  55  characters. 


16.  COUKSE_BOOKS 

This  relation  contains  data  on  the  required  textbooks 
for  currently  scheduled  courses.  Data  includes  the 
number  of  books  needed  for  the  course.  Each  entry  has 
a  maximum  length  of  72  characters. 


17.  COURSE_TIMES 

This  relation  contains  the  basic  course  scheduling  data 
for  all  the  resident  schools.  The  Status  and 
Uait_List_No  would  be  used  primarily  by  the  registrar 
and  represent  the  offering  status  (i.e.  "open  for 
registration")  and  the  number  of  students  on  the  wait¬ 
ing  list  for  the  course.  Each  entry  has  a  maximum 
length  of  37  characters. 

18.  CURRENT_CI_l>KOCKAMS 

This  relation  contains  data  pertinant  to  those  AFIT/CI 
programs  which  are  currently  active  and  have  students 
enrolled  in  them.  Each  program  is  indexed  to  the  LOCA¬ 
TIONS  relation  for  institution  name  and  address  and 
contains  a  POC  (Point  of  Contact)  for  the  particular 
program.  Each  entry  has  a  maximum  length  of  50  charac¬ 
ters  . 


19.  Cl'RRENT_THESF.S 

This  relation  contains  data  relevant  only  to  those 
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theses  currently  underway  at  AFIT,  e.q.  thesis  number 
and  thesis  committee.  Other  information  about  the 
thesis  itself  is  entered  into  the  THESES  relation  and 
remains  as  a  permanant  record  of  the  project.  These 
two  relations  are  connected  by  the  Thesis_No  attribute. 
Each  entry  has  a  maximum  length  of  51  characters. 


20.  DECREES 

This  relation  is  a  list  of  the  various  kinds  of  degrees 
which  students  and  faculty  may  be  (or  have  been) 
awarded.  Each  degree  is  identified  by  a  unique  five 
letter  code  which  shows  the  level  of  the  degree  and  the 
area  of  study  (i.e.  Masters  Degree  in  Electrical 
Engineering  -  MSEE).  Also  associated  with  each  code  is 
a  full  title  or  description  of  the  degree.  Each  entry 
has  a  maximum  length  of  55  characters. 

21.  DEGREE_S OUGHT 

This  relation  provides  data  on  the  degree,  major  and 
minor,  a  current  AFIT  student  is  seeking.  This 
Includes  both  resident  and  Cl  students.  Each  entry  has 
a  maximum  length  of  64  characters. 


22.  DF.JJATA 

This  relation  contains  student  data  peculiar  to  stu¬ 
dents  attending  the  School  of  Civil  Engineering 
(AFIT/DE).  Because  of  the  requirements  dictated  by 
AFIT/DE  needs,  certain  additional  student  data  must  be 
maintainedd  beyond  the  basic  data  found  in  the  STUDENTS 
relation.  The  data  in  STUDENTS  and  DE_DATA  are  linked 
by  the  students  SSAN.  Each  entry  has  a  maximum  length 
of  31  characters. 


23.  DUTY_0FFICER 

This  relation  contains  data  on  those  permanant  party 
officers  who  are  eligible  to  be  AFIT  duty  officers. 
The  credit  attribute  is  used  to  calculate  when  they 
will  stand  the  duty,  the  Date  attribute  tells  when  they 
are  scheduled  for  it  and  the  Duty  attribute  indicates 
which  list  duty  the  officer  is  assigned,  i.e.  Captain 
or  Major/Ltc.  Data  in  the  DUTY_0FFICER  and  STAFF  rela¬ 
tions  are  tied  by  the  SSAN  of  the  officer.  Each  entry 
has  a  maximum  length  of  25  characters. 


24.  ED_C0DF.S 

This  relation  contains  data  on  valid  educational  codes 
and  their  descriptions.  Each  entry  has  a  maximum 
length  of  34  characters. 
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25.  EDJIIST 

Tills  relation  contains  a  corapletet  list  of  the  institu¬ 
tions  a  student  has  attended  prior  to  arriving  at  his 
current  AFIT  tour.  A  description  of  the  degree  earned 
(if  any)  can  be  found  in  the  DEGREES  relation.  A  blank 
Degree_Code  entry  indicates  no  degree  was  achieved  for 
the  particular  period  denoted  by  Begin_Date  through 
End_Date.  Also  included  are  any  pertinant  remarks. 
Each  entry  has  a  maximum  length  of  115  characters. 

26.  ED_PLANS 

This  relation  contains  the  Education  Plan  of  each 
resident  student.  This  allows  the  tracking  of  the  pro¬ 
jected  courses  on  a  per  quarter  basis  as  well  as  the 
credit  hours.  It  is  assumed  that  only  plans  already 
approved  by  the  department  head  will  be  entered.  Each 
entry  har  a  maximum  length  of  20  characters. 

27.  EQUIPMENT 

This  relation  contains  the  necessary  data  to  plan  and 
track  any  orders  for  equipment,  furniture  or  supplies 
in  which  the  various  departments  within  AFIT  might  be 
Interested.  Another  possible  use  might  be  as  an  equip¬ 
ment  inventory  li6t.  Each  entry  has  a  maximum  length 
of  106  characters. 

28.  EXTRA_DUTIES 

This  relation  is  a  list  of  all  the  extra  duties  to 
which  a  AFIT  staff  member  might  be  assigned.  Each  duty 
title  or  description  is  identified  by  a  unique  six 
character  code  which  also  serves  as  an  abbreviated  form 
of  the  title.  Each  entry  has  a  maximum  length  of  56 
charac  ters . 


29.  EXTRA_DUTY_ROSTER 

This  relation  contains  data  on  all  personnel  assigned 
to  extra  duties,  the  duty(s)  to  which  they  are  assigned 
and  the  effictive  dates.  The  Extra_Duty_Code  keys  into 
the  EXTRA_DUTIES  relation  if  the  full  length  extra  duty 
title  is  needed.  Each  entry  has  a  maximum  length  of  21 
characters . 


30.  FACJJOARD 

This  relation  contains  general  information  pertaining 
to  the  reasons  for  and  actions  taken  on  a  particular 
Faculty  Board.  The  students  SSAN  will  link  this  rela¬ 
tion  with  additional  Information  on  the  student.  Suffi¬ 
cient  fields  are  provided  to  allow  previous  board 


Appendix  II) 


PAGE  5 


I 


actions  to  be  noted.  Each  entry  has  a  maximum  length 
of  207  characters. 


31.  FAC_BOARD_STUD_DATA 

This  relation  contains  the  students  academic  informa¬ 
tion  required  by  the  members  of  a  particular  faculty 
board.  An  '  cord  is  created  each  time  a  board  is 

held  for  a  student,  thus  providing  a  journal  of  his 
progress.  Each  entry  has  a  maximum  length  of  39  char¬ 
acters. 


32.  FAC_C0URSES 

This  relation  contains  data  on  an  instructors  schedule 
for  a  given  quarter.  For  those  courses  which  have  more 
than  one  instructor  participating,  the  Instruc tor_No 
attribute  identifies  which  instructor  he  is;  e.g.  "2" 
means  second  instructor  or  Instructor  number  2.  Each 
entry  has  a  maximum  length  of  2B  characters. 


33. 


FAC_ED 

l'his  relation  represents  an  educational  history  of  each 
faculty  member.  All  attributes  except  SSAN  are  free¬ 
form  text  fields  and  could  be  indexed  into  the  DECREES 
relation  if  formatted  appropriately.  Special  interests 
of  instructors  could  also  be  listed,  e.g.  microcomput¬ 
ers.  Each  entry  has  a  maximum  length  of  99  characters. 


34.  FAC_kEPLACEMENT 

This  relation  contains  data  on  projected  faculty 
replacements.  Each  replacement  is  uniquely  identified 
by  the  appropriate  position  number  (Pos_No) .  Each 
entry  has  a  maximum  length  of  157  characters. 


35.  FACJJOKK 

This  relation  represents  the  work  history  of  each 
faculty  member.  The  value  of  the  attribute  Rank  will 
vary  according  to  the  particular  type  of  employment  and 
the  given  rank  held  at  a  particular  time.  Thus,  if  two 
different  ranks  were  held  at  the  same  place  but  at  dif¬ 
ferent  times,  both  work  experiences  would  be  uniquely 
identified  and  entered.  F.ach  entry  has  a  maximum 
length  of  55  characters. 


36.  FORE  I GN_S T!  JDE NT_DATA 

This  relation  contains  data  unique  to  those  students 
who  are  members  of  foreign  Allied  Armed  Forces  such  as 
country  and  funding  source.  The  basic  student  data  is 
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kept  In  the  STUDENTS  relation.  Proper  use  of  this 
relation  assumes  that  a  method  of  identifying  foreign 
students,  similar  to  the  SSAN,  will  be  implemented 
within  AFIT.  Each  entry  has  a  maximum  length  of  41 
characters. 


37.  GRADES 

This  relation  contains  data  on  the  grades  for  each 
course  in  which  a  resident  student  is  enrolled.  Crades 
could  be  kept  on  a  quater  by  quarter  basis  only  or 
retained  for  the  duration  of  a  students  AFIT  assign¬ 
ment.  Each  entry  has  a  maximum  length  of  21  charac¬ 
ters. 


38.  IIOLDINCS 

This  relation  is  used  by  the  library  to  track  which 
office  has  what  library  material  checked  out.  Each 
entry  has  a  maximum  length  of  46  characters. 


39.  INSTITUTION_POCS 

This  relation  contains  the  POCs  (Points  of  Contact)  for 
each  civilian  institution.  Generally  this  will  be  the 
registrar  or  admissions  office  as  opposed  to  the  POCs 
for  n  particular  program  as  in  the  CURRENT_CI_PROCRAMS 
relation.  Further  Information  concerning  the  institu¬ 
tion  may  be  found  in  the  LOCATIONS  relation.  Each 
entry  has  a  maximum  length  of  45  characters. 


40.  inst_pay:ients 

This  relation  will  enable  AFIT/CI  to  maintain  a  record 
of  the  types  and  dates  of  payments  made  to  civilian 
Institutions.  The  type  of  payment  is  represented  by  a 
four  character  code  which  in  indexed  into  the 
ALLOWANCE/PAYMENT_TYPES  relation.  Further  information 
about  the  Institution  can  be  found  in  the  LOCATIONS 
relation.  Each  entry  has  a  maximum  length  of  23  char¬ 
acters  . 


41.  LOCATIONS 

This  relation  contains  the  code,  name  and  address,  on 
all  locations  of  interest  to  the  users  of  the  database. 
LOCATIONS  will  include  military  installations,  govern¬ 
ment  facilities,  civilian  institutions  and  Education 
With  Industry  locations.  Any  relation  requiring  addi¬ 
tional  information  about  a  location  may  index  into  this 
relation  by  using  the  attribute  Location_Code .  Each 
entry  has  a  maximum  length  of  85  characters. 
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42.  LOCKERS 

This  relation  maintains  data  on  the  availability  and 
disposition  of  student  lockers.  When  a  locker  has  been 
assigned,  the  students  SSAN  will  be  paired  with  the 
locker  number;  when  unassigncd  the  SSAN  attribute  for  a 
locker  tuple  will  be  empty  (blank).  This  will  allow 
all  unasslgned  lockers  to  be  identified.  Each  entry 
has  a  maximum  length  of  13  characters. 

43.  LI BKARY_BOOKS 

This  relation  contains  a  list  of  all  the  publications 
in  the  library  which  are  available  for  checkout  by  the 
students  and  faculty.  Each  entry  has  a  maximum  length 
of  80  characters. 


44.  MAJCOMS 

This  relation  contains  a  list  of  the  major  air  command 
abbreviations  and  their  full  title  (i.e.  SAC  ■  Stra¬ 
tegic  Air  Command).  Each  entry  has  a  maximum  length  of 
35  characters. 


45.  MF.D  BOARD  CERTIFICATION 

This  relation  is  comprised  of  a  students  medical  speci¬ 
alty  code,  his  individual  scores  for  medical  certifica¬ 
tion  tests,  the  dates  of  the  certification  and  the 
actual  test  scores.  Since  the  medical  specialty  code 
is  an  AFSC,  a  description  of  the  specialty  can  be  found 
in  the  AFSC  relation.  Each  entry  has  a  maximum  length 
of  48  characters. 


46.  MKD_PROCRAM 

This  relation  contains  data  peculiar  to  those  students 
who  are  enrolled  in  a  medical  program.  It  can  be  tied 
to  the  student  relation  via  SSAN.  Each  entry  has  a 
maximum  length  of  48  characters. 


47.  MED  TOURS 

This  relation  contains  a  list  of  the  assignments  a  med¬ 
ical  student  has  accumulated.  Each  entry  has  a  maximum 
length  of  32  characters. 


48.  MMEP 

The  data  in  this  relation  pertains  to  the  AF  bases  & 
supporting  Institutions  which  constitute  the  Mi  nut  eMail 
Education  Program.  Further  information  about  the  sup¬ 
porting  institution  and  base  can  be  found  in  the  LOCA¬ 
TIONS  relation.  Each  entry  has  a  maximum  length  of  10 


Appendix  ID 


PACE  8 


characters 


49.  MMEP  CLASSROOMS 

This  relation  is  a  list  of  the  rooms  and  buildings  used 
at  an  installation  for  the  MMEP  program.  Each  entry 
has  a  maximum  length  of  12  characters. 

50.  MMEP  FUNDING 

This  relation  contains  a  list  of  the  AF  MMEP  base  loca¬ 
tions  and  the  funding  source  of  the  program  along  with 
the  number  of  students  enrolled.  Each  entry  has  a  max¬ 
imum  length  of  10  characters. 

51.  NON_STU DENTS 

The  purpose  of  this  relation  is  to  track  those  people 
who  are  not  enrolled  in  AFIT  but  who,  for  some  reason, 
are  authorized  to  use  the  AFIT  library.  The  attribute 
Card  No  will  contain  the  users  SSAN  if  library  cards 
are  not  used.  Each  entry  has  a  maximum  length  of  69 
charac  ters . 


52.  OFFICES 

This  relation  consists  of  office  symbols  and  their 
corresponding  department  names.  Each  entry  has  a  max¬ 
imum  length  of  34  characters. 


53.  PAST  COURSES 

The  non-AFIT  courses  which  a  student  has  previously 
taken  but  which  did  not  lead  to  a  completed  degree 
could  be  recorded  in  this  relation.  Eac'r.  entry  has  a 
maximun  length  of  41  characters. 


54.  PCE 

This  relation  contains  data  concerning  non-resident 
Professional  Continuing  Education  (PCE)  courses  which 
are  offered  at  various  locations  under  the  auspices  of 
AFIT.  Additional  data  such  as  the  maximum  number  of 
students  allowed  in  the  course  and  the  actual  number 
enrolled  can  also  be  maintained.  Further  information 
about  a  course  can  be  obtained  by  indexing  into  the 
AFIT_Courses  relation.  Each  entry  has  a  maximum  length 
of  21  characters. 

55.  PREREQUISITES 

The  prerequisite  courses  for  any  given  course  are  con¬ 
tained  in  this  relation.  Because  only  a  single  course 
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and  one  prerequisite  are  listed  together,  the  user  is 
cautioned  to  perform  a  thorough  search  of  the  relation 
by  properly  constructing  his  query  to  insure  that  all 
required  data  is  retrieved.  Each  entry  has  a  maximum 
length  of  12  characters. 

56.  PRESENTATIONS 

Data  on  the  presentations  which  a.  faculty  member  gives 
is  contained  in  this  relation.  The  attribute  Location 
is  a  text  field  and  is  not  tied  to  the  LOCATIONS  rela¬ 
tion  since  many  unique  and  unusual  presentation  loca¬ 
tion  are  possible.  Additionally,  the  attribute  Organi¬ 
zation  denotes  the  organization  to  which  the  presenta¬ 
tion  was  given.  Each  entry  has  a  maximum  length  of  140 
characters . 


57.  PKOFESSIONAL_ORCS 

This  relation  contains  general  data  on  professional 
organizations,  and  their  full  names,  to  which  faculty 
und  staff  members  belong.  A  unique  identifier  code  is 
used  to  distinguish  between  the  organizations.  Each 
entry  has  a  maximum  length  of  55  characters. 


58.  PROF_FAC  ORGS 

This  reTation  contains  specific  data  pairing  a  given 
faculty  of  staff  member  with  a  particular  professional 
organization  code,  indicating  that  he  is  a  member  of 
the  associated  professional  organization.  The  attri¬ 
bute  Org  Abbrev  is  used  to  obtain  additional  informa¬ 
tion  about  the  organization  by  keying  into  the 
PROFESSIONAL_ORCS  relation.  Each  entry  has  a  maximum 
length  of  14  characters. 

59.  PROMOTION_STATS 

This  relation  is  to  be  used  by  AFIT/PA  to  analyse  and 
track  the  results  of  the  various  AF  boards  in  which 
AFIT  graduates  are  considered  for  promotion.  The 
attribute  BoardJUnd  will  be  determined  by  the  purpose 
of  the  particular  board  (i.e.  Capt,  Maj,  etc).  Each 
entry  has  a  maximum  length  of  26  characters. 


60.  PUBLICATIONS 

This  relation  contains  data  on  the  articles  and  books 
which  the  AFIT  faculty  publishes.  Each  entry  has  a 
maximum  length  of  190  characters. 
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61.  QUOTAS 

This  relation  will  be  used  by  AFIT/ED  to  keep  track  of 
the  estimated  and  actual  quotas  of  students  in  each 
educational  code.  Each  entry  has  a  maximum  length  of 
20  characters. 


62.  RESERVES 

This  relation  contains  data  on  books  and  publications 
which  are  placed  on  reserve  by  members  of  the  faculty. 
Each  entry  has  a  maximum  length  of  35  characters. 


63.  RESIDENT  DATA 

This  relation  contains  student  data  peculiar  to  AF1T 
resident  students.  Data  in  this  relation  was  only 
Identified  as  necessary  by  AFIT/EN  and  AFIT/LS.  Infor¬ 
mation  in  the  STUDENTS  and  RESIDENT_DATA  relations  are 
logically  connected  by  the  students  SSAN.  Each  entry 
has  a  maximum  length  of  98  characters. 


64.  ROOMS 

This  relation  is  a  list  of  the  rooms  within  AFIT  which 
can  potentially  be  scheduled  for  various  activities. 
The  attribute  Special__Roon_Type  is  used  to  denote  such 
things  as  a  secure  room,  auditorium,  laboratory  or  any 
other  room  with  special  features.  Each  entry  has  a 
maximum  length  of  11  characters. 


65.  ROOM  SCHEDULE 

This  relation  allows  the  centrally  schedulable  rooms  at 
AFIT  to  be  managed  in  order  to  forcast  and  track  their 
use  and  thus  eliminate  conflicts.  Each  entry  has  a 
maximum  length  of  46  characters. 

66.  SCHOOL/EWI_DATA 

This  relation  contains  data  which  pertains  to  civilian 
Institutions  and  Education  With  Industry  sites  for 
which  AFIT/CI  is  responsible.  Each  entrv  has  a  maximum 
length  of  17  characters. 


67.  SECTION 

This  relation  contains  data  on  current  AFIT  resident 
school  sections.  The  STUDENTS  relation  can  be  logi¬ 
cally  related  to  this  relation  by  either  the  attribute 
Section  or  Leader_SSAN.  Each  entry  has  a  maximum 
length  of  41  characters. 
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68.  SHORT__COURSE 

This  relation  contains  data  on  all  short  courses  taught 
at  AFIT.  Each  course  is  uniquely  identified  by  the  six 
character  attribute  Course.  Course  can  also  be  used  to 
index  into  the  AFlT_Courses  relation.  Each  entry  has  a 
maximum  length  of  109  characters. 


69.  SH0RT__STU  DENTS 

This  relation  functions  similarly  to  the  relation  STU¬ 
DENTS  but  only  maintains  data  on  non-resident  students 
such  as  part-time  or  short-course  students.  The  attri¬ 
bute  Course'  will  allow  this  relation  to  tie  into  the 
AFIT_C0URSES  relation  for  more  information  on  the 
course  itself.  Each  entry  has  a  maximum  length  of  90 
characters. 


70.  SPOUSES 

This  relation  allows  information  about  the  spouse  of 
both  students  and  faculty  to  be  retained.  The  attri¬ 
bute  SSAN  allows  this  relation  to  be  logically  related 
to  both  the  STAFF  and  STUDENTS  relation.  The  attribute 
Spouse_Type  distinguishes  between  staff  and  students 
spouses  and  the  attribute  Mill  tar y_Spouse  signifies  a 
spouse  who  is  also  in  the  military.  Each  entry  has  a 
maximum  length  of  49  characters. 


71.  STAFF 

This  relation  is  the  primary  repository  for  all  per¬ 
sonal  data  on  the  faculty  and  staff  of  AFIT.  Further 
information  on  most  of  the  attributes  can  be  obtained 
from  other  relations  as  required  by  indexing  into  them 
with  the  appropriate  common  attribute.  Each  entry  has 
a  maximum  length  of  232  characters. 


72.  STAFF_DE_DATA 

This  relation  contains  staff  data  peculiar  to  AFIT/DE. 
It  will  tie  into  the  STAFF  relation  by  means  of  the 
SSAN  of  the  staff  member.  Each  entry  has  a  maximum 
length  of  15  characters. 

73.  STAFF_P0S1TI0N_DATA 

This  relation  contains  data  on  the  education  levels 
associated  with  staff  positions.  Tuples  are  keyed  by 
position  number  and  data  is  given  on  ed  codes  and 
degree  levels,  both  required  and  assigned.  A  tie  into 
the  STAFF  relation  is  possible  via  SSAN.  Each  entry 
has  a  maximum  length  of  26  characters. 
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74.  STUDENTS 

This  relation  is  where  the  common  data  concerning  all 
students  other  than  part-time  and  short-course  students 
is  found.  These  attributes  are  those  most  commonly 
requested  by  all  the  AFIT  departments.  When  the  attri¬ 
bute  Foreign_Student_Ind  is  an  "F",  a  foreign  student 
is  denoted  and  additional  data  about  him  is  in  the 
FOREICN_STUDENTS  relation.  The  logical  link  between 
these  two  relations  is  the  students  SSAN.  For  all  stu¬ 
dents  the  attribute  Duty_Location  will  contain  the 
location  code  for  The  school  to  which  they  are 
assigned.  EN  and  LS  would  have  seperate  location 
codes.  Additionally,  the  attributes  GRE  and  CHAT  only 
contain  the  total  scores  for  that  test;  a  further 
breakdown  may  be  obtained  from  the  registrar.  Each 
entry  has  a  maximum  length  of  229  characters. 


75.  STUDENT_AWARDS 

This  relation  concerns  the  various  types  of  awards 
which  have  been  accorded  to  the  AFIT  students.  They 
may  include  official  decorations  and  scholastic  awards 
such  as  Dean's  List.  Each  entry  has  a  maximum  length 
of  45  characters. 


76.  STUDENTJIIST 

This  relation  could  contain  the  data  which  is  desired 
to  be  kept  on  previous  AFIT  students.  The  attribute 
SSAN  serves  as  the  only  key  although  a  secondary  index 
on  Name  might  be  possible.  Name  is  not  intended  as  a 
logical  link  into  any  other  relation.  However,  addi¬ 
tional  data  on  some  of  the  other  attributes  may  be 
obtained  as  required  by  using  other  logical  links. 
Each  entry  has  a  maximum  length  of  143  characters. 


77.  STUDE NT_PAYMENTS 

This  relation  contains  a  record  of  the  payments  made  by 
AFIT/CI  to  the  students  enrolled  in  their  programs. 
The  attribute  Payment_Type  is  the  same  as  the  attribute 
Allowance_Type  in  the  ALLOW  AfJCE_PAYMENTS  relation. 
Further  information  about  this  attribute  is  contained 
in  the  ALLOWANCE/ PA YMENT_TYPES  relation.  Each  entry 
has  a  maximum  length  of  40  characters. 


78.  STUDE NT_SCII ED 

This  relation  is  updated  each  quarter  from  the  regis¬ 
trars  office  and  contains  the  current  list  of  courses 
in  which  a  student  has  oflcially  enrolled.  By  logi¬ 
cally  linking  with  the  COURSC_TIMES  relation,  a  stu¬ 
dents  schedule  can  be  determined.  The  logical  link  to 
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Room_Schedule  could  also  be  followed  to  find  a  student 
during  an  emergency  while  he  was  In  clat-i.  bach  entry 
has  a  maximum  length  of  15  characters. 


79.  SUBSCRIPTIONS 

This  relation  contains  data  on  the  periodicals  to  which 
the  library  subscribes.  Each  entry  has  a  maximum 
length  of  147  characters. 


80.  TDY 

This  relation  contains  information  concerning  the  TDY 
trips  taken  by  both  staff  and  students.  The  attributes 
will  not  only  allow  for  recording  projected  trip  costs 
but  also  the  actual  cost  once  the  trip  has  been  com¬ 
pleted.  Each  entry  has  a  maximum  length  of  81  charac¬ 
ters. 

81.  THESES 

This  relation  contains  the  general  information  required 
on  all  AFIT  theses.  It  will  provide  a  library  of  data 
about  completed  theses  thus  allowing  quick  and  easy 
access  to  historical  data.  Current  theses  will  be 
listed  here  also  and  logically  linked  to  the 
CURRENT_TUESES  relation  by  the  attribute  Thesis_No. 
The  CURRENT_THESES  relation  is  concerned  only  with  on 
going  projects.  Once  a  current  thesis  is  completed  it 
is  removed  from  CURRENT_THESES  and  the  only  record  of 
it  will  remain  in  this  relation.  Each  entry  has  a  max¬ 
imum  length  of  159  characters. 


82.  TIIESIS_SPONSORS 

This  relation  contains  a  list  of  sponsors  of  a  resident 
AFIT  thesis  along  with  their  location.  Further  infor¬ 
mation  about  the  location  can  be  found  in  the  LOCATIONS 
relation.  Each  entry  has  a  maximum  length  of  60  char¬ 
acters. 


The  following  relations  pertain  strictly  to  the  regis¬ 
trars  function  at  AFIT.  After  examing  the  contents,  struc¬ 
ture  and  intent  of  the  current  data  system  in  use  at  AFIT/RR 
(INTERACT),  these  relations  were  designed  to  work  in  concert 
with  the  above  relations  yet  still  allow  the  functions 
currently  being  performed  to  be  fulfilled.  It  is  felt  that 
with  these  basic  relations  and  the  capabilities  of  a  good 
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DBMS  Che  registrars  requirements  and  functions  can  be 
Included  with  only  a  relatively  few  applications  programs 
and  no  loss  of  capability* 

Because  present  situations  may  preclude  the  registrar 
from  being  included  into  a  single  consolidated  AFIT  database 
at  this  time,  the  above  relations  were  designed  with  their 
exclusion  being  a  definite  possibility.  Therefore,  if  and 
when  the  registrar  is  included,  some  of  the  previous  rela¬ 
tions  could  be  reduced  in  size  to  eliminate  the  small  amount 
of  overlap  which  would  occur. 


83.  COURSEjCRADES 

This  relation  would  be  the  permanent  grade  record  of 
each  course  taken  by  a  student.  All  of  these  records 
for  a  student  would  comprise  a  major  portion  of  his 
transcript.  Each  entry  has  a  maximum  length  of  58 
charac  ters . 


84.  COURSERS TATS 

This  relation  contains  statistics  for  each  course 
currently  offered  within  AFIT  and  it  is  assumed  they 
are  cumulative.  However,  if  this  is  not  the  desired 
method,  the  addition  of  the  attributes  Quarter  and  Year 
as  keys  will  eliminate  any  duplicate  entries  and  allow 
data  to  be  maintained  for  each  quarter.  Each  entry  has 
a  maximum  length  of  24  characters. 

85.  CMAT_SCORES 

This  relation  contains  the  total  CHAT  score  for  a  par¬ 
ticular  student.  A  GMAT  indicator  and  the  students 
SSAN  could  serve  as  a  logical  link  into  this  relation. 
Each  entry  has  a  maximum  length  of  12  characters. 

86.  CRE_S  CORES 

This  relation  contains  a  breakdovm  of  the  GRE  scores 
for  a  particular  student.  If  this  relation  is  incor¬ 
porated  the  total  score  will  no  longer  have  to  be  kept 
seperate  in  other  student  relations,  it  can  be  computed 
as  required.  A  CRE  indicator  and  the  students  SSAN 
could  be  used  to  logically  link  into  this  relation. 
Each  entry  has  a  maximum  length  of  18  characters. 

87.  RR_DATA 

This  relation  contains  student  data  specifically 
required  by  the  registrar.  The  attributes  CRE_Ind  and 
GMAT  Ind  are  used  to  denote  which  set  of  tests  the 
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student  took;  the  scores  can  be  found  by  indexing  into 
the  appropriate  relation  using  the  students  SSAN.  Each 
entry  has  a  maximum  length  of  77  characters. 


88.  TRANSFERS 

This  relation  contains  the  data  required  for 
students.  Each  entry  has  a  maximum  length  of 
acters. 


transfe  r 
^8  char- 
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RELATIONS  FOR  THE  CONSOLIDATED  AFIT  DATABASE 
KEYS  FOR  EACH  RELATION  ARE  DENOTED  BY  "*"s 


0*~ 


1.  ACADEMIC_TITLES: 

Academic__Title_Code* ,  Academic_Title. 

2.  AFIT_CALENDAR: 

Day*,  Month*,  Year*,  Starting_Time* ,  Activity, 
CC_Activity,  Room*,  Building*,  POC,  Remarks. 

3.  AFITjCOURSES: 

Course*,  Title,  Description,  Min_Credit, 

Max_Credit,  Special^Crading ,  Section_Control , 
Remarks,  Lec__Hrs,  Lab_Hrs,  Student_Limit , 

Special_Room_Type . 

4 .  AFSC : 

AFSC* ,  Description. 

5 .  ALLOWANCE_PAYMENTS : 

SSAN*,  Allowance_Type* ,  Date_Paid*,  Amount. 

6.  ALLOWANCE / PAYM  E  NT_T Y  PE  S : 

Allowance_Type* ,  Description. 

7.  AUDIO_V  IS : 

Title*,  Time,  Producer*,  Speaker,  Subject, 
Production  Date. 


8.  AWARDS: 

SSAN*,  Award,  Date*. 

9.  BINDINGS: 

Title*,  Volume,  Month, 
Letter  Color. 


Year,  Color  No, 


10.  BOOKS: 

Title*,  Author*,  Publisher,  No_Avail,  Price, 

Office. 

11.  ROOK_ORDF.R5: 

Author,  Title,  Ordef_No*,  No_0rdered,  Date, 

Status . 

12.  BOXES: 

SSAN*,  Box  No*. 


13.  CHECKOUTS: 

Call  No*,  Patron_Name,  lD_No* ,  Due_Date. 
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14.  C I_DATA : 

SSAN*,  Program,  Output_AFSC,  Degree_Code, 
Prlor_CPA,  Avallable_Date ,  Prior_AFIT, 

Departure_Reason,  Suspense  Date,  Logo l_Residence, 
Thesis_Pay,  Suspense_Actlon,  Status,  Begin_Date, 
C_GPA,  Term_GPA. 

15.  CI_PROGRAMS: 

Program*,  Description. 


16. 

COURSEJJOOKS: 

Course*,  Author*,  Title*,  No  Required, 
Year* .  ' 

Quarter* 

17. 

COURSE  TIMES: 

Course*,  Starting  Time*,  Day*,  Quarter* 
Room,  Building,  Course  Status,  Wait 
Begin  Date,  End  Date. 

,  Year* 
List  No 

18. 

CURRENT_C  I_PROGRAMS : 

Location  Code*,  Program*,  POC,  DPhone. 

19. 

CURRENT_TUESES: 

SSAN*,  Thesis  No,  Advisors  SSAN,  Readerl, 

Reader2 

20. 

DECREES: 

Degree  Code*,  Description. 

21. 

DECREE_SOUCHT: 

SSAN*,  Degree  Code,  Major,  Minor. 

22. 

DEJJATA: 

SSAN*,  DAFSC,  Func t_Acct_Code ,  DOS,  Ar rival_Date . 

23. 

DUTY_OFFICER: 

SSAN*,  Duty,  Credit  Date,  Duty  Date. 

24. 

F.D  CODES: 

Ed_Code* ,  Ed_Code_Title. 

25. 

ED_HIST: 

SSAN*,  College*,  Begin  Date, 

Degree  Code,  Departure  Reason,  Remarks. 

End  Date 

26. 

ED_PLANS: 

SSAN*,  Course*,  Quarter*,  Year*,  Credits. 

27. 

EQUIPMENT: 

Stock  No*,  Description,  Price,  Date_ 

Date  Received,  Availability,  Office. 

Ordered* 

Append  lx 
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28. 

29. 

30. 

31. 

32. 

33. 

34. 

35. 

36. 

37. 

38. 

39. 


EXTRA_DUTIES: 

Ex t ra_Du ty_Code* ,  Ex  t ra_Du  ty_Ti tl e . 

EXTRA_DUTY_ROSTE  R : 

SSAN*,  Extra__Duty_Code* ,  Date. 

FAC_B0ARD: 

SSAN*,  Trouble_Term ,  Quarter*,  Year*, 

Trouble_Year ,  Reason,  Initial_Analysis, 

Board_Action,  Success,  Remarks. 

FAC_BOARD_STUD_DATA : 

SSAN*,  'Quarter*,  Year*,  UC_CGPA,  CRE,  GHAT, 
Term_GPA,  C_GPA,  A_Cred ,  B_Cred ,  C_Cred. 

FAC_COURSES : 

SSAN*,  Course*,  Quarter*,  Year*,  Instruc tor_No , 
Group_Contact_Hrs,  Ind_Contact_Hrs . 

FAC_ED: 

SSAN*,  Pr imary_Ed_Level ,  Secondary  Ed  Level, 

Speclal_Interest .  ~  ” 

FAC_REPLACEHENT: 

Pos_No*,  Office,  DAFSC,  Rank,  Name,  Arr lval_Dace , 
Degree_Required ,  Academic_Spec laity.  Status, 

DPhone. 

FAC_WORK: 

SSAN*,  Location*,  Rank*,  Begin_Date,  End_Date. 

FOREIGN_STUDENTSJDATA : 

ID_No*,  Service,  Country,  Funding. 

CRADES: 

SSAN*,  Course*,  Quarter*,  Year*,  Grade. 

HOLDINGS : 

Title*,  Office*,  Begln__Date,  Eud_l)ate. 

IHSTITUTION_POCS: 

Location  Code*,  POC,  DPhone. 


40.  1NST_PAYMENTS: 

Location  Code*,  Date*,  Payment  Type*,  Amount. 


41.  LOCATIONS: 

Location  Code*,  Location  Name,  Local  Address. 


42.  LOCKERS: 

SSAN*,  Locker  No*. 
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oT 


A3. 

4A. 

45. 

46. 

47. 

48. 

49. 

50. 

51. 

52. 

53. 

54. 

55. 

56. 

57. 


LIBRARYB00KS: 

Call  No*,  Title,  Author. 

MAJCOM S: 

MAJCOM* ,  MAJCOM_Title. 

MED_BOARD_CERTIFICATION: 

SSAN*,  Hed_Spec_Code* ,  Certlfication_Date, 
A  NAT  Score,  PIlYS_Score,  BIOCll_Score ,  PATll_Score, 
MICRO_Score,  PHARM_Score,  BEHSCI_Score , 

Score_Date. 

MF.D_PROCRA'l: 

SSAN*,  MCAT_Score,  MCAT_Score_Date ,  Degree_Code, 
Med_Program,  Access lon_Source. 

MEI)_T0URS: 

SSAN*,  Med_Spec_Code,  Location_Code* ,  Begin_Date*, 
End_Date. 

MMEP : 

Locatlon_Code* ,  Supporting_Inst_Code. 
MMEP_CLASSROOMS: 

Locatlon_Code* ,  Room*,  Building*. 

MMEP_FUNDING: 

Locatlon_Code* ,  Fund_Type*,  No_Students. 

NON_STUDE  NTS : 

Name,  Card_No*,  Organization,  DPhone. 

OFFICES: 

Office*,  Of fice_Title. 

PAST_COURSES: 

SSATT*,  College*,  Course*,  Crade,  Quarter*,  Year*. 
PCE: 

Course*,  Location_Code* ,  MAJCOM*,  Student_Limi t , 
No_Students. 

PREREQUISITES: 

Course*,  Prerequisite*. 

PRESENTATIONS: 

SSAN*,  Date*,  Title,  Location,  Organization*,  Sub¬ 
ject. 

PR0FESSI0NAL_0RCS: 

Org  Abbrev*,  Org  Name. 
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58. 

59. 


60. 


61. 

62. 

63. 


64. 

65. 


66. 

67. 


68. 


69. 


70. 


71. 


PR0F_FAC_0RCS : 

SSAN*,  Org_Abbrev*. 

PR0M0TI0N_STATS: 

Board_Date* ,  BoardJCind*,  USAF,  AFIT,  USAF_Elig, 
AFIT_Elig. 

PUBLICATIONS: 

SSAN*,  Title*,  Date,  Subject,.  Source*,  Location, 
Pub__K  i  nd  ,  Co_Au  t  h_Na  me  . 

QUOTAS : 

Ed_Code* ,  Quota_Type*,  YR1 ,  YR2,  YR3,  YR4 ,  YR5. 
RESERVES: 

Call_No*,  FAC_SSAN’*,  Date  Reserved*. 

RESIDE  NT_DATA : 

SSAN*,  Last_Organiza tion,  Duration,  DOC, 

Emergency  Address. 

ROOMS: 

Room*,  Building*,  Max_Size,  Special_Room_Type . 
ROOM_SCHEDULE : 

Day*,  Month*,  Year*,  Starting_Time* ,  Ending_Tirae, 
Room,  Building*,  Function. 

SCHOOL/ EWI_DATA: 

Location_Code* ,  Servicing_AFO,  Tuition_Rate . 
SECTION: 

Section*,  Graduation_Date,  Entry_Date, 

No_Students,  Leader_SSAN,  Advisors_SSAN, 

No_Non_AF. 

S1!ORT_COURSE: 

Course*,  Title,  Begin_Date*,  End_Date,  Room*, 
Building*,  Starting_Tiue ,  Description. 

SHORT_STUUENTS: 

SSAN*,  Course*,  Begin_Date*,  Name,  Rank,  Organiza¬ 
tion,  DPhone 

SPOUSES: 

Sponsors_SSAN* ,  Name,  DOB,  h’o_Deps,  Spouse_Type, 
Mi litary_Spouse . 

STAFF: 

SSAN*,  Name,  Rank,  HPhone ,  DPhone,  Room,  Office, 
Pos_No,  Duty_Title,  Date_Assigned ,  Depar ture_Date , 
Local  Address,  DOB,  DOR,  Acad_Ti tle_Code ,  DOAR, 
Marital  Status,  Sex,  PAFSC,  DAFSC,  Ethnic_Croup , 
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TMST 


I 


ef? 


Service,  PhotoJDate,  Security_Clearance, 
Previous_MAJCOM. 

72.  STAFF_DE_DATA: 

SSAN* ,  Course_Directed*. 

73.  STAFF_POSITION_DATA: 

Pos_No*,  SSAN,  Ed_Code_Required ,  Ed_Code_As signed , 
Degree_Level  Required,  Degree_Level_Assigned . 

74.  STUDENTS: 

SSAN*,  Name,  Rank,  PAFSC,  Ed_Code,  DOR,  Sex,  DOB, 
Advisors_SSAN,  Entry_Date,  DPhone,  HPhone, 
Local_Address ,  Foreign_Service_Ind ,  Service, 
Departure_Date ,  Secur ity_Clearance,  Duty_Location, 
Aero_Rating,  Previous  MAJCOM,  Marital_Status , 
TMST,  EthnicjGroup,  CRE,  GMAT,  Duty_Title,  Sec¬ 
tion,  Academic_Standing. 

75.  STUDENT_AWARDS: 

SSAN*,  Award,  Date*. 

76.  STUDENTJ1IST: 

SSAN*,  Name,  Rank,  PAFSC,  Ed__Code,  Sex, 
Entry_Date,  Departure_Date,  Service, 

Local_Address,  Addre6S_Date ,  Aero_Rating, 

Marital_Status,  EthnicjCroup,  CRE,  CMAT, 
Degree_Code. 

77.  STUDENTJPAYMENTS: 

SSAN*,  ESA_No* ,  Date*,  Payment_Type* ,  Amount. 

78.  STUDENT_SCHED: 

SSAN*,  Course*. 

79.  SUBSCRIPTIONS: 

Title*,  Check_In,  Renewal_Date ,  Price, 

Expiration_Date ,  Requester,  Begin_Date, 

Follow_Up_Date ,  Follow_Up_Remarks . 

80.  TDY: 

Destination*,  SSAN*,  Depar ture_Date* ,  Return_Date, 
Estimated_Cost,  Actual  Cost, Fees,  Per_Diem, 

Travel . 

81.  THESES: 

Thesis_No*,  Title,  Thesis_Sponsor,  Classification, 
First_Author ,  Second_Author ,  Subject, 

Thesis  Pub  Date,  DTIC  No,  Cleared  For  Release. 


« 
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RELATIONS  PERTAINING  TO  THE  REGISTRARS  INFORMATION 


83.  COURSE_CRADES: 

SSAN*,  Course*,  Grade__Type,  Grade,  Prior_Crade, 
Registered_Hrs,  Earned_Jlrs,  Qual_Pts,  Drop_Reason, 
Date. 

84.  COURSE_STATS: 

Course*,  Pro j_Enrollment ,  Min_Enrollment , 

No_Enrolled,  Demand,  Drops,  Wait_List_No , 
No_Not_Registered ,  No_Added,  No_Audits. 

85.  GMAT_SCORES: 

SSAN* ,  Total. 

86.  CRE_SCORES : 

SSAN*,  Verbal,  Quantitative,  Total. 

87.  RR_DATA: 

SSAN*,  Manning_Code ,  Output_MAJCOM ,  UC_CGPA, 
Degree_Code,  Prior_AFIT,  Folder_Location, 

Departure_Reason,  Admission_Action,  Transferlnd , 
Prev  CPA,  C  CPA,  CRE_Ind,  GMAT_Ind ,  Re  Admit  Term, 
Academic  Elig,  Calc  Required  Term, 

Degree_Checkout ,  Admin  Jiold,  ReAdmitYear , 

Calc  Required_Year . 

88.  TRANSFERS: 

SSAN*,  Location  Code* ,  TRF_llrs,  TRF  Qual  Hrs, 
TRF  Qual  Pts,  Begin  Date,  Quarter,  TRF  In  Date, 
TRF  End  Date,  Old  Code. 
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LOGICAL  DATABASE  VIEWS,  RELATIONAL  LEVEL  FOR 
CADIS,  BY  OFFICE 


LOCICAL  DATABASE  VIEW  FOR: 
SCHOOL  OF  CIVIL  ENGINEERING  (AFIT/DE) 


1. 

2. 


3. 


4. 

20. 

22. 

24. 

25. 


33. 


36. 

41. 

44. 


ACADEMIC  TITLES: 

Academic  Title  Code*,  Academic_Title . 
APIT_CALENDAR: 

Day*,  Month*,  Year*,  Star ting_Time* ,  Activity, 
CC_Activity,  Room*,  Building*,  POC,  Remarks. 

AFITJCOURSES: 

Course*,  Title,  Description,  Min_Credit, 

tlax_Credit,  SpecialjGrading,  Section_Control , 
Remarks,  Lec_llrs,  Lab_llrs,  Student_Limit , 

Special_Room_Type . 

AF  SC: 

AFSC* ,  Description. 

DECREES: 

DegreeCode* ,  Description. 

DEDATA: 

SSAN*,  DAFSC,  Funct_Acct_Code ,  DOS,  ArrivalDate. 
ED_C0DES: 

EdCode*,  Ed_Code_Tltle. 

ED_HIST: 

SSAN*,  College*,  Begin  Date,  End_Date, 
Degree_Code,  Departure  Reason,  Remarks. 

FAC  ED: 

SSAN*,  Primary_Ed_Level ,  Secundary_Ed__Level , 
Special  Interest. 

FOREICN_STUDENTS_DATA : 

ID  No*,  Service,  Country,  Funding. 

LOCATIONS: 

Location  Code*,  Location  Name,  Local  Address. 
MAJCOMS : 
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MAJCOM* ,  MAJCOM  Title 
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52.  OFFICES: 

Office*,  Office  Title. 

53.  PAST  COURSES: 

SSAN* ,  College*,  Course*,  Grade,  Quarter*,  Year*. 

70.  SPOUSES: 

Sponsors  SSAN*,  Name,  DOB,  No  Deps,  Spouse  Type, 
Military  Spouse. 

71.  STAFP :  ’ 

SSAN*,  Name,  Rank,  HPhone,  DPhone,  Room,  Office, 
Pos  No,  Duty  Title,  Date  Assigned,  Departure  Date, 
Local_Address ,  DOB,  DOR,  Acad_Title_Code ,  DOAR, 
Marital_Status,  Sex,  PAFSC,  DAFSC,  Ethnic_Group, 
Service,  Photo_Date,  Security_Clearance,  TMST, 
Pr ev i ou  s_MA JCOMT 

72.  STAFF_DE_DATA: 

SSAN*,  Course_Directed* . 

74.  STUDENTS: 

SSAN*,  Name,  Rank,  PAFSC,  Ed_Code,  DOR,  Sex,  DOB, 
Advisors_SSAN,  Entry__Date,  DPhone,  HPhone, 
Local_Address,  Foreign_Service_Ind,  Service, 
Departure_Date ,  Secur ity_Clearance,  Duty_Location, 
Aero_Rating,  Previous^MAJCOM,  Marital_Status, 
TMST,  EthnicjGroup,  CRE,  CMAT,  DjtyJTitle,  Sec¬ 
tion,  Academic  Standing. 


•« 
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LOCICAL  DATABASE  VIEW  FOR: 


CIVILIAN  INSTITUTION  PROGRAMS  (AFIT/CI) 


2.  AFIT_CALENDAR: 

Day*,  Month*,  Year*,  Star ting_Time* ,  Activity, 
CC  Activity,  Room*,  Building*,  POC,  Remarks. 

4.  AFSC: 

AFSC* ,  Description. 

6.  ALLOW ANCE/PAYMENT_TYPES : 

Allowance_Type* ,  Description. 

14.  CI_DATA: 

SSAN* ,  Program,  Output__AFSC,  Degree_Code,  Prior_CPA, 
Available_Date,  Prior_AFIT,  Departure_Reason, 

Suspense  Date ,  Legal_Residence,  Thesis_Pay, 

Suspense_Action,  Status,  Begin_Date,  C_GPA,  Term_GPA. 

15.  CI_PROGRAMS: 

Program*,  Description. 

18.  CURRENT_CI_PROGRAMS: 

LocationjCode* ,  Program*,  POC,  DPhone. 

20.  DECREES: 

Degree_Code* ,  Description. 

21.  DP/’  '  CUT: 

SSAN*,  Degree_Code,  Major,  Minor. 

24.  ED_C0DF.S: 

Ed_Code*,  Ed_Code_Title . 

2  5.  FDJIIST: 

SSAN*,  College*,  Begin_Date,  End_Date,  Degree_Code, 
Departure  Reason,  Remarks. 


26. 

ED_PLANS: 

SSAN*,  Course*,  Quarter*, 

Year*,  Credits. 

36. 

FOREICN_STUDENTS_DATA : 

ID  No*,  Service,  Country, 

Funding . 

37. 

GRADES: 

SSAN*,  Course*,  Quarter*, 

Year*,  Grade. 

39. 

INSTITUTION  POCS: 

Location  Code*,  POC,  DPhone. 
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AA. 

A5. 


A6. 


A7. 


A8. 

A9. 

50. 

53. 

5A. 


66. 

70. 


7A . 


INST_PAYMENTS: 

Location_Code* ,  Date*,  Payment_Type* ,  Amount. 

LOCATIONS : 

Location  Code*,  Location_Name ,  Local_Address . 

MAJCOMS : 

MAJCOM* ,  MAJCOM_Title . 

MED_BOARD_CERTIFICATION: 

SSAN*,  Med_Spec_Code* ,  Certif ication_Date ,  ANAT_Score, 
PllYS_Score,  BIOCH_Score,  PATll_Score,  MICRO_Score, 
PHARM_Score,  BEHSCI_Score ,  Score_Date. 

MED_PROCRAM : 

SSAN*,  MCAT__Score,  MCAT_Score_Date ,  Degree_Code, 

Med_Program ,  Accession_Source . 

MED_TOURS : 

SSAN*,  Med_Spec_Code ,  Location_Code* ,  Begin_Date*, 

End_Da  te . 

MMEPs 

Location_Code* ,  Supporting_Inst_Code . 

MMEP_C  LASS ROOMS: 

Location_Code* ,  Room*,  Building*. 

MMEP_FUNDING: 

Location_Code* ,  Fund_Type*,  No_Students. 

PASTjCOURSES: 

SSAN*,  College*,  Course*,  Crade,  Quarter*,  Year*. 


PCE: 

Course*,  Location_Code* ,  MAJCOM*,  Student_Limit , 
No  Students. 

SCH00L/EWI_DATA: 

Location_Code* ,  Servicing_AFO,  Tuition_Rate. 

SPOUSES: 

Sponsor  s_SSAN*,  Name,  DOB,  No_Deps,  Spouse_Type, 
Military_Spouse . 

STUDENTS: 

SSAN*,  Name,  Rank,  PAFSC,  FH_Code,  DOR,  Sex,  DOB, 
Advisors_SSAN,  Entry_Date,  DPhone,  HPhone, 
Local_Address,  Foreign_Service_lnd ,  Service, 

Departure  Date,  Secur ity_Clearance ,  Duty_Location , 
Aero  Rating,  Previous_MAJCOM,  Mari tal_Status ,  TMST, 
Ethnic_Croup,  CRE,  CMAT ,  Duty_Title,  Section, 
Academic  Standing. 
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77.  STUDCNT_PAYMENTS: 

SSAN*,  ESA_No* ,  Date*,  Payment  Type*,  Amount. 


78.  STUDENT_SCUED: 

SSAN*,  Course*. 
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LOGICAL  DATABASE  VIEW  FOR: 
ACADEMIC  LIBRARY  (AFIT/LD) 


1. 

2. 


3. 


4. 

7. 


9. 

11. 

12. 

13. 

17. 


24. 

36. 

38. 

41. 


ACADEMIC_TITLES : 

Academic_Title_Code* ,  Academic_Title. 

AFITjCALENDAR: 

Day*,  Month*,  Year*,  Star ting_Time* ,  Activity 

CC_Activity,  Room*,  Building*,  POC,  Remarks. 

AKITCOURSES: 

Course*,  Title,  Description,  Min  Credit,  Max  Credit 
Special_Crading,  Section_Control ,  Remarks,  Lec_Hrs 
Lab_Hrs,  Student_Limit ,  Special_Room_Type . 

AFSC: 

AFSC*,  Description. 


AUDIO_VIS: 

Title*,  Time,  Producer*,  Speaker,  Subject 
Produc  tion_Da  te . 

B1NDINCS: 

Title*,  Volume,  Month,  Year,  Color_No,  Letter_Color . 
BOOK_ORDERS: 

Author,  Title,  Order_No*,  No_Ordered ,  D?te,  Status. 
BOXES : 

SSAN*,  Box  No*. 


CHECKOUTS: 

Call_No*,  Patron  Name,  ID  No*,  Due  Date. 


COURSE  TIMES: 


Course*,  Starting_Time* ,  Day*,  Quarter*, 
Building,  Course_Status ,  Wait_List_No 


Year* ,  Room 
,  Begin  Date 


End  Date. 


EDjCODES : 

Ed_Code* ,  Ed_Code_Title. 

FOREICN_STUDENTS_DATA : 

ID_No*,  Service,  Country,  Funding. 


HOLDINCS: 

Title*,  Office*,  Begin  Date,  End  Date. 


LOCATIONS: 

Location  Code*,  Location  Name,  Local  Address. 


Appendix  IG 


PACE  6 


w 
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43.  LIBRARY_BOOKS : 

Call_No*,  Title,  Author. 

44.  MAJCOMS: 

MAJCOM* ,  MAJCOM_Title. 

51.  NONJSTUDENTS : 

Name,  Card_No*,  Organization,  DPhone. 

52.  OFFICES: 

Office*,  Of fice_Title. 

60.  PUBLICATIONS: 

SSAN*,  Title*,  Date,  Subject,  Source*,  Location, 
Pub_Ki nd ,  Co_Au  th_Name . 

62.  RESERVES: 

Call_No* ,  FAC_SSAN* ,  Da te_Re served* . 

68.  SHORT_COURSE: 

Course*,  Title,  Begin_Date*,  End_Date,  Room*,  Build¬ 
ing*,  Starting_Time ,  Description. 

69.  SHORT_STUDENTS: 

SSAN*,  Course*,  Begin_Date*,  Name,  Rank,  Organization, 
DPhone 

71.  STAFF: 

SSAN*,  Name,  Rank,  HPhone,  DPhone,  Room,  Office, 
Pos_No,  Duty_Title,  Da te_As signed ,  Departure_Date , 
Local_Address,  DOB,  DOR,  Acad_Title_Code,  DOAR, 
Marital_Status ,  Sex,  PAFSC,  DAFSC,  Ethnic_Group,  Ser¬ 
vice,  P'noto_Date,  Secur  ity_Clearance,  TMST, 

Previous_MAJCOM . 

74.  STUDENTS: 

SSAN*,  Name,  Rank,  PAFSC,  Ed_Code,  DOR,  Sex,  DOB, 
Advisors_SSAN,  Entry_Date,  DPhone,  HPhone, 
Local_Address,  Foreign_Service_Ind ,  Service, 

Departure_Date ,  Secur ity_Clearance ,  Duty_Location, 
Aero_Rating,  Previous_MAJCOM,  Marital_Status,  TMST, 
Ethr.  Ic_Croup,  CRE,  CMAT,  Duty_Title,  Section, 
Academic_Standing. 

79.  SUBSCRIPTIONS : 

Title*,  Check_In,  Renewal_Date,  Price, 

Expiration_Date ,  Requester,  Begin_Date, 

Fo 1 low_U p_Da  t e ,  Fo 1 low_U p_Reraa rk s . 

81.  THESES: 

Thesis_No*,  Title,  Thesis  Sponsor,  Classification, 
First_Author ,  Second_Author"7  Subject,  Thesis_Pub_Date , 
DTIC_No ,  Cleared_For_Release . 
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82.  THE  S IS_S  PO  NS  OR  S : 

Thesis  Sponsor*, 
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LOGICAL  DATABASE  VIEW  FOR: 
DIRECTOR  OF  ACADEMIC  AFFAIRS  (AFIT/CAE) 


1.  ACADEM IC_T  ITLES : 

Academic_Title_Code* ,  Acad emlc_Ti tie. 

2.  AF IT_CALENDAR : 

Day*,  Month*,  Year*,  Star ting_Time* ,  Activity, 

CC_Activity,  Room*,  Building*.  POC,  Remarks. 

3.  AFIT  COURSES: 

Course*,  Title,  Description,  Min  Credit,  Max  Credit, 
Special  Grading,  SectionControl,  Remarks,  Lee  llrs, 
Lab  llrs,  Student  Limit,  Special  Room  Type. 

4.  AFSC: 

AFSC* ,  Description. 

5 .  ALLOWANC  EPAYM  ENTS : 

SSAN*,  Allowance_Type* ,  Date_Paid*,  Amount. 

6.  ALLOWANC E/ PAYM ENT_TY PE S: 

Allowance_Type* ,  Description. 

7.  AUDIO_VIS: 

Title*,  Time,  Producer*,  Speaker,  Subject, 
Product ion_Date . 

8.  AWARDS : 

SSAN* ,  Award,  Date*. 

9.  BINDINCS: 

Title*,  Volume,  Month,  Year,  Color_No,  Letter_Color. 

10.  BOOKS: 

Title*,  Author*,  Publisher,  No_Avail,  Price,  Office. 

11.  ROOK_ORDERS: 

Author,  Title,  Order  No*,  No_0rdered,  Date,  Status. 

12.  BOXES: 

SSAN*,  Box_No* . 

13.  CHECKOUTS: 

Call_No*,  Patron_Name ,  lD_No*,  Due_Date. 

14.  CI_DATA: 

SSAN*,  Program,  Output_AFSC,  Degree  Code,  Prior_CPA, 
Available_Date ,  Prlor_AFlT,  ~Departure_Reason, 

Suspense  Date,  Legal__Resldence,  Thesis_Pay, 


Appendix  IG 


PAGE  9 


Suspense  Action,  Status,  Begin  Date,  Cj.FA,  ferm_GPA. 

15.  CI_PROGRAMS: 

Program*,  Description. 

16.  COURSE_BOOKS : 

Course*,  Author*,  Title*,  No_Required,  Quarter*, 
Year* . 

17.  COURSE_TIMES: 

Course*,  Starting_Time* ,  Day*,  Quarter*,  Year*,  Room, 
Building,  Course_Status,  Wait_List_No ,  Begin  Date, 
End_Date.  "  ~ 

18.  CURRENT_CI_PROGRAMS: 

Location_Code* ,  Program*,  POC,  DPhone. 

19.  CURREKT_THESES : 

SSAN*,  Thesis_No,  Advisors_SSAN,  Readerl,  Reader2. 

20.  DEGREES: 

Degree  Code*,  Description. 


«** 


21.  DEGREE_S OUGHT: 

SSAN*,  Degree_Code,  Major,  Minor. 

22.  DE_DATA: 

SSAN*,  DAFSC,  Funct_Acct_Code,  DOS,  Arrival_Date . 

23.  DUTYOFFICER: 

SSAN*,  Duty,  Credit_Date,  Duty_Date. 

24.  ED_C0DES: 

Ed_Code* ,  Ed_Code_Ti tie . 

25.  KDJIIST: 

SSAN*,  College*,  Begin_Date,  End_Date,  Degree_Code, 
Departure  Reason,  Remarks. 

26.  ED_PLANS: 

SSAN*,  Course*,  Quarter*,  Year*,  Credits. 

27.  EQUIPMENT: 

Stock_No*,  Description,  Price,  Date_Ordered* , 
Date  Received,  Availability,  Office. 


28.  EXTRA_DUTIES: 

Extra_Duty_Code* ,  Extra_Duty_Ti tie . 

29.  EXTRA_DUTY_ROSTER: 

SSAN*,  Extra  Duty  Code*,  Date. 
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30. 

FAC_BOARD: 

33 

SSAN*,  Trouble_Term,  Quarter*,  Year*,  Trouble  Year 

Reason,  Initial_Analysis,  hoard  Action,  Success 

»_  *  - 
»_  * 

Remarks. 

31. 

FAC_BOARD_STUD_DATA : 

SSAN*,  Quarter*,  Year*,  UC_CCPA,  GRE,  CMAT,  Term  GPA 

m 

C_GPA,  A__Cred,  B_Cred,  C  Cred . 

32. 

FAC_COURSES: 

SSAN*,  Course*,  Quarter*,  Year*,  Instructor  Ho 

i 

33. 

Croup_Contact_Hrs,  Ind  Contact  Hrs. 

FAC_ED: 

SSAN*,  Prlmary_Ed_Level ,  Secondary  Ed  Level 

Special  Interest.  ~  ~ 

34. 

FAC_REPLACEMEtfT: 

>  • 

Po8_No*,  Office,  DAFSC,  Rank,  Name,  Arrival  Date 

** 

►  "r*1— 

Degree_Required ,  Academic  Specialty,  Status,  DPhone. 

35. 

FAC_WORK: 

-  .*• 

SSAN*,  Location*,  Rank*,  Begin_Date,  End  Date. 

L\ 

36. 

KOKEICN_STUDENTS_DATA : 

i  or 

»■ . 

ID_No* ,  Service,  Country,  Funding. 

37. 

GRADES: 

SSAN*,  Course*,  Quarter*,  Year*,  Grade. 

38. 

liOLDINCS: 

m 

Title*,  Office*,  Begin  Date,  End  Date. 

aw 

39. 

INSTITUTION_POCS: 

|  - 

Locatlon_Code* ,  POC,  DPhone. 

40. 

INST_PAYMENTS : 

Locatlon_Code* ,  Date*,  Payment  Type*,  Amount. 

41. 

LOCATIONS: 

Location_Code* ,  Location  Name,  Local  Address. 

42. 

LOCKERS: 

. 

SSAN*,  Locke r_No*. 

43. 

LIBRARY_B00KS : 

Call_No*,  Title,  Author. 

44. 

MAJCOMS: 

\  • 

MAJCOM* ,  MAJC0M_T1 tie . 

r:  * 

45. 

MF.D_B0ARD_C  ERT I F I C  AT  ION : 

SSAN*,  Med  Spec  Code*,  Certification  Date,  ANAT  Score 
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PHYS_Score,  BI0CU_Score,  PATH  Score, 

P11ARH  Score,  BEHSCI  Score,  Score  Date. 

MICRO  Score, 

46. 

MED_PROCRAM : 

SSAN*,  MCAT  Score,  MCAT  Score  Date, 

Med_Program ,  Accession  Source. 

Degree  Code, 

47. 

MED_T0URS: 

SSAN*,  Med_Spec_Code,  Location  Code*, 

End  Date. 

Begin_Date* , 

• 

00 

-«iT 

MMEP: 

Location_Code* ,  Supporting  Inst  Code. 

49. 

MHE  P_jC  LASS  ROOM  S : 

Location  Code*,  Room*,  Building*. 

50. 

MMEP_FUNDINC: 

Location  Code*,  Fund  Type*,  No  Students. 

51. 

NON_STUDENTS: 

Name,  Card  No*,  Organization,  DPhone. 

52. 

OFFICES: 

Office*,  Office  Title. 

53. 

PAST_COURSES: 

SSAN*,  College*,  Course*,  Crade,  Quarter*, 

Year*. 

54. 

PCE: 

Course*,  Location_Code* ,  MAJCOM* ,  Student  Limit, 

No_Students. 

55. 

PREREQUISITES: 

Course*,  Prerequisite*. 

56. 

PRESENTATIONS: 

SSAN*,  Date*,  Title,  Location,  Organizatio 

n*,  Subject. 

57. 

PROFESS I0NAL_0RGS: 

Org^Abbrev* ,  Org_Name . 

00 

• 

PROF  FAC_0RGS : 

SSAN*,  Org  Abbrev*. 

59. 

PROMOTION  STATS: 

Board  Date*,  Board  Kind*,  USAF,  AFIT, 

AFIT_Elig. 

USAF_Elig, 

60. 

PUBLICATIONS: 

SSAN*,  Title*,  Date,  Subject,  Source*, 
Pub  Kind,  Co  Auth  Name. 

Location, 
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62. 

63. 


64. 

65. 


66. 

67. 


68. 


69. 


70. 


71. 


72. 

73. 


74. 


Ed_Code* ,  Quota_Type*,  YRl ,  YR2,  YR3,  YR4,  YR5. 
RESERVES : 

Call_No*,  FAC_SSAN*,  Da te_Re served* . 

RESIDE  NT_DATA : 

SSAN*,  La st_0rganiza tion ,  Duration,  DOC 

Emergency_Address . 

ROOMS: 

Room*,  Building*,  Max_Size,  Special_Room_Type . 
R00M_SCHEDULE : 

Day*,  Month*,  Year*,  Star ting_Time* ,  Ending_Time 
Room,  Building*,  Function. 

SCHOOL/EWI_DATA: 

Location_Code* ,  Servicing_AFO,  Tuition_Rate . 

SECTION: 

Section*,  Craduation_Date ,  Entry_Date,  No_Students 
Leader_SSAN,  Advisors_SSAN,  Non_AF. 

SHORT_COURSE: 

Course*,  Title,  Begin_Date*,  End_Date,  Room*,  Build¬ 
ing*,  Starting_Time ,  Description. 

S110RT_STUDENTS : 

SSAN*,  Course*,  Begin_Date*,  Name,  Rank,  Organization 
DPhone 


SPOUSES: 

SponsorsSSAN* ,  Name,  DOB,  Mo_Deps,  SpouseType 
Mi litar ySpouse . 


STAFF : 

SSAN* ,  Name ,  Rank , 
Pos  No,  DutyTitle, 
Local_Addres8 ,  DOB, 
Marltal_Status,  Sex, 
vice,  Photo_Date, 
Previous  MAJCOM. 


HPhone ,  DPhone,  Room,  Office 
Date  Assigned ,  Departure  Date 
DOR,  Acad_Title_Code,  DOAR 
PAFSC,  DAFSC,  Ethnic_Group,  Ser- 
Security  Clearance,  TMST 


STAFF_DE_DATA : 

SSAN*,  Course  Directed*. 


STAFF_POSITION_DATA : 

Pos_No*,  SSAN,  Ed_Code_Required ,  Ed_Code_As signed 
Degree_Level_Requlred  ,  Deg ree_Level_As signed . 


STUDENTS: 

SSAN*,  Name,  Rank,  PAFSC,  Ed_Code,  DOR,  Sex,  DOB, 
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Advisors__SSAN,  Entry_Date,  DPhone,  HPhone, 
Local_Address ,  Foreign_Service_Ind ,  Service, 

Departure_Date,  Security_Clearance,  Duty_Location, 
Aero_Rating,  PreviousMAJCOM,  Marital_Status ,  TMST, 
Ethnic_Group,  CRE,  CHAT,  Duty_Title,  Section, 
Academic_Standing . 

75.  STUDENT_AWARDS : 

SSAN*,  Award,  Date*. 

76.  STUDENTJIIST: 

SSAN*,  Name,  Rank,  PAFSC,  Ed_Code,  Sex,  Entry_Date, 
Departure  Ddte,  Service,  Local_Address ,  Address  ate, 
Aero_Rating,  Marital_Status ,  Ethnic_Croup,  CRE,  C.1AT, 
Degree_Code . 

7  7 .  STUDENT_PAYMENTS : 

SSAN*,  ESA_No*,  Date*,  Payment_Type* ,  Amount. 

78.  STUDENTJSC11ED: 

SSAN*,  Course*. 

79.  SUBSCRIPTIONS: 

Title*,  Check_In,  Renewal_Date,  Price, 

Expiration_Date,  Requester,  Begin_Date, 

Follow_Up_Date ,  Follow_Up_Remarks . 

80.  TDY: 

Destination*,  SSAN*,  Departure_Date* ,  Return_Date, 
Estimated_Cost,  Actual_Cost,Fees,  Per_Diem,  Travel. 

81.  THESES: 

The8is_No*,  Title,  Thesis_Sponsor ,  Classification, 
Flrst__Author,  Second_Author,  Subject,  Thesis_Pub_Date, 
DTIC  No,  Cleared  For  Release. 


82.  THESIS_SPONSORS: 

Thesis  Sponsor*,  Location. 


RELATIONS  PERTAINING  TO  THE  REGISTRARS  INFORMATION 


83.  COURSEjGRADES : 

SSAN*,  Course*,  Crade_Type,  Crade,  Prior_Crade, 
Registered  Hrs,  Earned Jlrs,  Qual_Pts,  Drop_Reason, 
Date . 

•  __  84.  COURSE_STATS: 

~  '  Course*,  Proj  Enrollment,  Min_Enrollment,  No_Enrolled, 

Demand,  Drops,  Wait_Llst_No ,  No_Not_Registered , 
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No_Added ,  No_Aud its. 

85.  CMAT_SCORES: 

SSAN*,  Total. 

86.  CRE_SCORES: 

SSAN*,  Verbal,  Quantitative,  Total. 

87.  RR  DATA: 

SSAN* ,  Manning  Code,  Output_MAJCOM,  UG_CGPA, 

Degree_Code,  Prior_AFIT,  Folder_Location, 

Departure_Reason,  Admission  Action,  Transfer  Ind, 
Prev  CPA,  C  GPA,  GRE  Ind,  GMAT  Ind,  Re  Admit  Term, 
Academic  Elig,  Calc  Required  Term,  Degree  Checkout, 
Admin  Hold,  Re  Admit  Year,  Calc  Required  Year. 

88.  TRANSFERS: 

SSAN*,  Location  Code*,  TRF  Hrs,  TRF  Qual  Urs, 
TRF  Qual  Pts,  Begin__Date,  Quarter,  TRF_In  Date, 
TRF  End  Date,  01d_Code. 


OT 
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LOGICAL  DATABASE  VIEW  FOR: 
COMMAND  SECTION,  COMMANDANT  (AFIT/CC) 


1.  ACADEMIC_TITLES: 

Academic_Title_Code* ,  Acaderaic_Title . 

2.  AFIT_CALENDAR: 

Day*,  Month*,  Year*,  Starting_Time* ,  Activity 
CC_Activity,  Room*,  Building*,  POC,  Remarks. 


3. 

AFITJCOURSES: 

Course*,  Title,  Description,  Min  Credit,  Max  Credit 
Special  Grading,  Section  Control,  Remarks,  Lee  Hrs 
Lab  Urs,  Student  Limit,  Special  Room  Type. 

4. 

AFSC: 

AFSC*,  Description. 

5. 

ALLOW ANCE_PAYMENTS : 

SSAN*,  Allowance  Type*,  Date  Paid*,  Amount. 

6. 

ALLOW ANCE/PAYMENT_TYPES : 

Allowance_Type* ,  Description. 

7. 

AUDIO_VIS: 

Title*,  Time,  Producer*,  Speaker, 

Production  Date. 

Subject 

8. 

AWARDS : 

SSAN*,  Award,  Date*. 

9. 

BINDINGS : 

Title*,  Volume,  Month,  Year,  Color_No,  Letter 

Color. 

10. 

BOOKS: 

Title*,  Author*,  Publisher,  No_Avail,  Price, 

Office. 

11. 

B00K_0RDERS: 

Author,  Title,  Order  No*,  No  Ordered,  Date, 

Status . 

12. 

BOXES : 

SSAN*,  Box_No* . 

13. 

CHECKOUTS: 

Call  No*,  Patron  Name,  ID  No*,  Due_Date. 

14. 

Cl  DATA: 

SSAN* ,  Program,  Output_AFSC,  Degree_Code,  Prior_CPA 
Availabie_Date,  Prior_AFIT,  Departure_Reason 
Suspense  Date,  Legal_Residence ,  Thesis_Pay 
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hi 

* 

Suspense  Action,  Status,  Begin  Date,  C  GPA,  Tens  CPA. 

s 

15. 

Cl  PROGRAMS: 

Program*,  Description. 

16. 

COURSE  BOOKS: 

Course*,  Author*,  Title*,  No  Required,  Quarter*, 

9 

Year* . 

J 

17. 

COURSE  TIMES: 

Course*,  Starting  Time*,  Day*,  Quarter*,  Year*,  Room, 

Building,  Course  Status,  Wait  List  No,  Begin  Date, 

End  Date. 

1 

18. 

CURRENT_CI_PROGRAMS : 

Location  Code*,  Program*,  POC,  DPhone. 

*  ; 

19. 

CURRENT  THESES: 

SSAN*,  Thesis  No,  Advisors  SSAN,  Readerl,  Reader2. 

3 

20. 

DECREES: 

Degree  Code*,  Description. 

;* 

21. 

DECREE  SOUGHT: 

«  «f«- 

SSAN*,  Degree  Code,  Major,  Minor. 

22. 

DE  DATA: 

SSAN*,  DAFSC,  Funct  Acct  Code,  DOS,  Arrival  Date. 

23. 

DUTY  OFFICER: 

a 

SSAN*,  Duty,  Credit  Date,  Duty  Date. 

24. 

ED  CODES: 

EcT_Code*,  Ed_Code_Title. 

!  ■ 

25. 

ED  HIST: 

« 

SSAN* ,  College*,  Begin_Date,  End_Date,  Degree_Code, 
Departure  Reason,  Remarks. 

26. 

ED  PLANS: 

SSAN*,  Course*,  Quarter*,  Year*,  Credits. 

27. 

EQUIPMENT: 

M 

. 

Stock  No*,  Description,  Price,  Date  Ordered*, 

Da te  "Received ,  Availability,  Office. 

. ' 

28. 

EXTRA  DUTIES: 

.  ■  - 

Extra  Duty  Code*,  Extra__Duty  Title. 

4 

r*  ■  — 

L 

29. 

EXTRA_DUTY_ROSTER: 

SSAN*,  Extra  Duty_Code*,  Date. 

»,  * 

4 

>-  - 
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30. 

31. 

32. 

33. 

34. 

35. 

36. 

37. 

38. 

39. 

40. 

41. 

42. 

43. 

44. 

45. 


FAC_B0ARD: 

SSAN*,  Trouble_Term,  Quarter*,  Year*,  Trouble_Year , 
Reason,  Initial_Analysis ,  Board_Action,  Success, 
Remarks. 

FAC_B0ARD_S  TU  D_DATA : 

SSAN* ,  Quarter*,  Year*,  UCjCGPA,  GRE,  GMAT,  Tenn_GPA, 
C_GPA,  AjCred ,  BjCred,  C_Cred. 

FAC_COURSES: 

SSAN*,  Course*,  Quarter*,  Year*,  Instructor  No, 
Croup_Contact_Hrs,  Ind_Contac  t_Hrs . 

FAC_ED: 

SSAN*,  Primary_Ed_Level ,  Secondary_Ed_Level , 

Special_Interest . 

FAC_RE PLACEMENT: 

Pos_No*,  Office,  DAFSC,  Rank,  Name,  Arrival  Date, 
Degree_Required ,  Academic_Specialty ,  Status,  DPhone. 

FAC_WORK: 

SSAN*,  Location*,  Rank*,  Begin_Date,  End_Date. 

FORE 1CN_STUDE  NT  S_DATA : 

ID_No*,  Service,  Country,  Funding. 

GRADES: 

SSAN*,  Course*,  Quarter*,  Year*,  Crade. 

HOLDINGS : 

Title*,  Office*,  Begin_Date,  End_Date. 

INSTITUTION_POCS: 

Location_Code* ,  POC,  DPhone. 

INST_PAYMENTS: 

Location_Code* ,  Date*,  Payment  Type*,  Amount. 
LOCATIONS: 

Location_Code* ,  Location  Name,  Local  Address. 

LOCKERS: 

SSAN*,  Locker  No*. 

LIBRARY  BOOKS: 

Call  No*,  Title,  Author. 

MAJCOMS: 

MAJCOM* ,  MAJCOM  Title. 

MED  BOARD  CERTIFICATION: 

SSAN*,  Med  Spec  Code*,  Certification  Date,  ANAT  Sc^re, 
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46. 

47. 

48. 

49. 

50. 

51. 

52. 

53. 

54. 

55. 

56. 

57. 

58. 

59. 

60. 


PHYS  Score,  BIOCH_Score,  PATH_Score,  MlCRO_Score 
PHARM_Score,  BEllSCI  Score,  Score_Dace. 

MED  PROGRAM: 

SSAN*,  MCAT_Score,  MCAT_Score_Date,  Degree_Code 

Med_Program,  Accession_Source . 

MED_T0URS : 

SSAN*,  Med_Spec_Code,  Location_Code* ,  Begin_Date* 

End_Date . 

MMEP: 

Location_Code* ,  Supporting  Inst  Code. 

1IMEP  CLASSROOMS: 

Location_Code* ,  Room*,  Building*. 

MMEP_FUNDING: 

Location_Code* ,  Fund_Type*,  No_Students. 

NON  STUDENTS: 

Name,  Card_No*,  Organization,  DPhone. 

OFFICES: 

Office*,  Of f ice_Ti tie. 

PAST_COURSF.S: 

SSAN* ,  College*,  Course*,  Grade,  Quarter*,  Year*. 

PCE: 

Course*,  Location_Code* ,  MAJCOM* ,  Student_Limit 
No_Students . 

PREREQUISITES: 

Course*,  Prerequisite*. 

PRESENTATIONS: 

SSAN*,  Date*,  Title,  Location,  Organization*,  Subject 

PR0FESSI0NAL_0RCS : 

Org_Abbrev*,  Org_Name. 

PR0F_FAC_0RGS : 

SSAN*,  0rg_Abbrev*. 

PR0M0TI0N_STATS: 

Board_Date* ,  Board_Kind*,  USAF,  AFIT,  USAF_Elig 
AFlT_Elig. 

PUBLICATIONS: 

SSAN*,  Title*,  Date,  Subject,  Source*,  Location 
Pub  Kind,  Co  Auth  Name. 
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61. 

62. 

63. 


64 . 

65. 


66. 

67. 


68. 


69. 


70. 


71. 


72. 

73. 


74. 


QUOTAS: 

Ed_Code* ,  QuotaJType*,  YR1 ,  YR2,  YR3,  YR4,  YR5. 
RESERVES: 

Call_No* ,  FAC_SSAN* ,  Date_Reserved* . 

RESIDE  NT_DATA : 

SSAN*,  Last_Organization,  Duration,  DOC, 

Emergency_Address . 

ROOMS : 

Room*,  Building*,  Max_Slze,  Special_Rootn_Type . 
ROOM_SCHEDULE : 

Day*,  Month*,  Year*,  Starting_Time* ,  Ending_Time, 
Room,  Building*,  Function. 

SCHOOL/ F.WI_DATA: 

Location_Code* ,  Servic ing_AF0,  Tuition_Rate . 

SECTION: 

Section*,  Craduatlon_Date,  Entry_Date,  No_Students, 
Leader_SSAN,  Advisors_SSAN,  Non_AF. 

SHORT_COURSE: 

Course*,  Title,  Begin_Date*,  End_Date,  Room*,  Build¬ 
ing*,  Starting_Time,  Description. 

SHORT  STUDENTS: 

SSAN^,  Course*,  Begin_Date*,  Name,  Rank,  Organization, 
DPIione 

SPOUSES: 

Spon8or8_SSAN* ,  Name,  DOB,  No_Deps,  Spouse_Type, 
Mi litary_Spouse . 

STAFF : 

SSAN*,  Name,  Rank,  HPhone,  DPhone,  Room,  Office, 
Pos_No,  Duty__Title,  Date_Assigned ,  Departure_Date, 
Local_Address ,  DOB,  DOR,  Acad_Title_Code,  DOAR, 
Marital_Status ,  Sex,  PAFSC,  DAFSC,  Er  ._Croup,  Ser¬ 
vice,  Photo_Date,  Security_Cl»  ^e,  TMST , 
Previous_MAJCOM . 

STAFF_DE_DATA : 

SSAN*,  Course_Dlrected* . 

STAFF_POSITION_DATA : 

Pos_No*,  SSAN',  Ed_Code_Required ,  Ed_Code_Ass  igned , 
Degree_Level_Required ,  Deg ree_Level_Assigned . 

STUDENTS: 

SSAN*,  Name,  Rank,  PAFSC,  Ed_Code,  DOR,  Sex,  DOB, 
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Advisors_SSAN,  Entry_Date,  DPhone,  HPhone, 
Local_Address ,  Foreign__Service_Ind ,  Service, 

Departure_Date,  Security_Clearance,  Duty_Location, 
Aero_Rating,  Previous_MAJCOM,  Marital_Status ,  TMST, 
Ethnic_Croup,  CRE,  GI1AT,  Duty_Title,  Section, 
Academic_Standing . 

75.  STUDENT_AWARDS : 

SSAN*,  Award,  Date*. 

76.  STUOENTJIIST: 

SSAN*,  Name,  Rank,  PAFSC,  Ed_Code,  Sex,  Entry_Date, 
Departure_Date ,  Service,  Local_Address,  Address  Date, 
Aero_Rating,  Marital_Status ,  Ethnic_Croup,  CRE,  CM AT, 
Degree_Code . 

77.  STUDENT_PAYMENTS: 

SSAN*,  ESA_No*,  Date*,  Payment_Type* ,  Amount. 

78.  STUDENT_SCHED: 

SSAN*,  Course*. 

79.  SUBSCRIPTIONS: 

Title*,  Check_In,  Renewal_Date ,  Price, 

Expiration_Date ,  Requester,  Begin_Date, 

Follow_Up_Date ,  Follow_Up_Remarks . 

80.  TDY : 

Destination*,  SSAN*,  Depar ture_Date* ,  Return_Date, 
Estimated_Cost ,  Actual_Cost .Fees ,  Per_Diera,  Travel. 

81.  THESES: 

Thesis_No*,  Title,  Thesis_Sponsor ,  Classification, 
Fir8t_Author ,  Second_Author ,  Subject,  Thesis_Pub_Date , 
DTIC  No,  Cleared  For  Release. 


82.  THESIS_SP0NS0RS: 

Thesis_Sponsor* ,  Location. 


RELATIONS  PERTAINING  TO  THE  REGISTRARS  INFORMATION 

83.  COURSE  GRADES: 

SSAN*,  Course*,  Crade  Type,  Crade,  Prior_Crade, 
Registered_lir  s ,  Earned_Hrs,  Qual_Pts,  Drop_Reason, 
Date . 

84.  COURSE  STATS: 

Course*,  Proj  Enrollment,  Min  Enrollment,  No  Enrolled, 
Demand,  Drops,  Wa it_List_No ,  No  Not  Registered, 


Appendix  IG 


PAGE  21 


No_Added ,  No_Aud its* 

85.  CHAT  SCORES: 

SSAN*.  Total. 

86.  GRE  SCORES: 

SSAN* ,  Verbal,  Quantitative,  Total. 

87.  RR  DATA: 

SSAN* ,  Manning_Code,  Output_MAJCOM,  UGjGCPA , 

Degree__Code,  Prior  AFIT,  Folder_Location, 

Departure  Reason,  Admission  Action,  Transfer  Ind, 
Prev_GPA,~C_CPA,  GRE^Ind,  GMAT_Xnd,  Readmit  JFerm , 
Academic_Elig ,  Calc_Required_Term,  Degree^Checkout , 
Admin_Hold,  Re_Admit_Year ,  Calc_Required  Year. 

88.  TRANSFERS: 

SSAN*,  Location_Code*,  TRF_Hrs ,  TRF_Qual.Hrs, 
TRF_Qual__Pts,  Begin_Date»  Quarter,  TRF__In_Date, 

TRF  End _Date,  Old  Code. 
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LOGICAL  DATABASE  VIEW  FOR: 


DIRECTORATE  OF  ADMINISTRATION  (AFIT/DA) 


1.  ACADEMIC  TITLES: 

Academic  Title  Code*,  Academic  Title. 

2.  AFIT  CALENDAR: 

Day*,  Month*,  Year*,  Starting  Time*,  Activity 
CC_Activity,  Room*,  Building*,  POC,  Remarks. 

3.  AFIT_COURSES: 

Course*,  Title,  Description,  Min_Credit,  Max_Credit 
Special_Grading ,  Section_Control ,  Remarks,  Lec_Hrs 
Lab_llrs,  Student  Limit,  Special_Room  Type. 


4. 

AFSC: 

AFSC* ,  Description. 

8. 

AWARDS : 

SSAN*,  Award,  Date*. 

10. 

BOOKS: 

Title*,  Author*,  Publisher,  No_Avail, 

Price,  Office. 

11. 

B00K_0RDERS: 

Author,  Title,  Order_No*,  No_0rdered, 

Date,  Status. 

12. 

BOXES: 

SSAN*,  Box_No*. 

16. 

COURSE  BOOKS: 

Course*,  Author*,  Title*,  No_Required,  Quarter* 
Year* . 

17.  COURSE_TLMES: 

Course*,  Starting_Time* ,  Day*,  Quarter*,  Year*,  Room 
Building,  Course_Status  ,  Wa i t_Li s t_No ,  Begin _Date 
End  Date. 

I'l.  CURRENT JTHESES: 

SSAN*,  Thesis_No,  Advisors__SSAN,  Reader  1,  Reader2. 

2U.  DECREES: 

Degree_Code* ,  Description. 

23.  DUTY_OFFICER: 

SSAN* ,  Duty,  Credit_Date,  Duty  Date. 

24.  ED  CODES: 
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Ed  Code*,  Ed  Code  Title. 


25.  ED  HIST: 

SSAN*,  College*,  Begin  Date,  End  Date,  Degree_Code, 
Departure_Rea8on,  Remarks.  “ 


• 

00 

N 

EXTRA_DUTIES : 

Extra_Duty_Code* ,  Extra  Duty  Title. 

• 

O' 

CM 

EXTRA_DUTY_ROSTER: 

SSAN*,  Extra  Duty  Code*,  Date. 

32. 

FAC_COURSES: 

SSAN*,  Course*,  Quarter*,  Year*,  Instructor  No, 

Croup  Contact  Hrs,  Ind  Contact  Hrs. 

34. 

FAC_REPLACEMENT : 

Pos  No*,  Office,  DAFSC,  Rank,  Name,  Arrival  Date, 
Degree  Required,  Academic_Specialty ,  Status,  DPhone. 

36. 

FOREICN  STUDENTS  DATA: 

ID_No*,  Service,  Country,  Funding. 

41. 

LOCATIONS: 

Location_Code* ,  Location  Name,  Local  Address 

• 

44. 

MAJCOMS: 

MAJCOM* ,  MAJCOMTitle. 

52. 

OFFICES: 

Office*,  Office  Title. 

55. 

PREREQUISITES: 

Course*,  Prerequisite*. 

5(). 

PRESENTATIONS: 

SSAN*,  Date*,  Title,  Location,  Organization* 

,  Subject. 

60. 

PUBLICATIONS : 

SSAN*,  Title*,  Date,  Subject,  Source*, 
PubJCind,  Co  Auth_Name. 

Location, 

63. 

RESIDE  NT_DATA : 

SSAN*,  Last_Organization,  Duration, 

Emergency_Address . 

DOC, 

64. 

ROOMS: 

Room*,  Building*,  Max__Size,  Spec  ial_Room_Type . 

65.  ROOM_SCHEDULE: 

Day*,  Month*,  Year*,  Star ting_Time* ,  Ending_Time, 

Room,  Building*,  Function. 
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67.  SECTION: 

Section*,  Craduation_Date ,  Entry_Date,  No_Students, 
Leader_SSAN,  Advisors_SSAN,  Non_AF. 

70.  SPOUSES: 

Spon8ors_SSAN* ,  Name,  DOB,  No_Deps,  Spouse_Type, 
Milicary_Spouse. 

71.  STAFF: 

SSAN*,  Name,  Rank,  HPhone,  DPhone,  Room,  Office, 
Pos_No,  Duty_Title,  Date_Assigned ,  Depar ture_Date , 
Local_Address,  DOB,  DOR,  Acad_Title_Code,  DOAR, 
Marital_Status ,  Sex,  PAFSC,  DAFSC,  Ethnic_Croup,  Ser¬ 
vice,  Photo_Date,  Security_Clearance ,  TMST, 
Pr ev ious_MAJCOM . 

73.  STAFF_POSITION__DATA : 

PosNo*,  SSAN,  Ed_Code_Required ,  Ed_Code_Assigned , 
Degree_Level_Required ,  Degree_Level_Assigned . 

74 .  STUDENTS: 

SSAN*,  Name,  Rank,  PAFSC,  Ed_Code,  DOR,  Sex,  DOB, 
Advisors_SSAN,  Entry_Date,  DPhone,  HPhone, 

Local  Address,  Foreign_Service_Ind ,  Service, 

Departure_Date ,  Secur lty_Clearance,  Duty_Location , 
Aero_Rating,  Previous_MAJCOM,  Mar ital_Status ,  TMST, 
Ethnic  Croup,  CRE,  GMAT,  Duty_Title,  Section, 
AcadcaTc_St ending. 

80.  TDY: 

Destination*,  SSAN*,  Depar ture_Da t e* ,  Return_Date, 
Estimated_Cost,  Actual_Cost .Fees ,  Per_Diem,  Travel. 

81.  THESES: 

The8is_No*,  Title,  Thesis_Sponsor,  Classification, 
First_Author ,  Second_Author,  Subject,  Thesis_Pub_Date , 
DTIC  No,  Cleared  For  Release. 


82.  THESIS_SP0NS0RS: 

Thesis_Sponsor*,  Location. 
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LOGICAL  DATABASE  VIEW  FOR: 
OFFICE  OF  PUBLIC  AFFAIRS  ( AFIT/PA) 


1.  ACADEMIC_TITLES: 

Acadanic_Title_Code* ,  Academic_Title. 

2.  AFITjCALENDAR: 

Day*,  Month*,  Year*,  Starting_Time* ,  Activity, 
CC_^Activity,  Room*,  Building*,  POC,  Remarks. 

4.  AFSC: 

AFSC*,  Description. 

8.  AWARDS: 

SSAN*,  Award,  Date*. 

19.  CURRENTJTHESES: 

SSAN*,  Thesis_No,  Advisors_SSAN,  Readerl,  Reader2. 

20.  DECREES: 

DegreejCode* ,  Description. 

21 .  DEGREE_SOUGHT: 

SSAN*,  Degree_Code,  Major,  Minor. 

24.  EDjCODES: 

Ed_Code* ,  Ed_Code__Title. 

25.  ED_HIST: 

SSAN*,  College*,  Begin__Date,  End_Date,  Degree_Code, 
Departure_Reason,  Remarks. 

36.  FORE I GN_STU  DE  NT  S_DA  TA : 

ID_No*,  Service,  Country,  Funding. 

41.  LOCATIONS: 

Location_Code* ,  Location_Name ,  Local_Address . 

44.  MAJCOMS: 

MAJCOM* ,  MAJCOM_T i t 1 e . 

52.  OFFICES: 

Office*,  Of fice_Title. 

56,  PRESENTATIONS: 

SSAN*,  Date*,  Title,  Location,  Organization*,  Subject. 

57.  PR0FESSI0NAL_0RGS: 

Org  Abbrev* ,  Org  Name. 
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58.  PROF_FAC_ORCS : 

SSAN* ,  Org_Abbrev* . 

59.  PROMOTION_STATS: 

Board  Date* ,  BoardJCind*,  USAF,  AFIT,  USAF_Elig, 
AFIT_Elig. 

60.  PUBLICATIONS: 

SSAN*,  Title*,  Date,  Subject,  Source*,  Location, 
Pub__Kind,  Co_Auth_Naoe  • 

61.  RESIDE  NTJIATA: 

SSAN*,  "Last  Organization,  Duration,  DOC, 

Emergency  Address. 

67.  SECTION: 

Section*,  Craduation_Date,  Entry_Date,  No_Students, 
Leader_J>SAN,  Advisors_SSAN,  Non_AF . 

70.  SPOUSES: 

Sponsors__SSAN*,  Name,  DOB,  No_Deps,  Spouse_Type, 
Military_Spouse . 

71.  STAFF: 

SSAN*,  Name,  Rank,  HPhone,  DPhone,  Room,  Office, 
Pos  No,  Duty  Title,  Date  Assigned,  Departure  Date, 
Local_Address,  DOB,  DOR,  Acad_Title_Code,  DOAR, 
Marital_Status,  Sex,  PAFSC,  DAFSC,  EthnTc_Croup,  Ser¬ 
vice,  Photo_Date,  SecurityjClearance ,  TMST, 
Previous_MAJC(JM . 

74.  STUDENTS: 

SSAN*,  Name,  Rank,  PAFSC,  Ed_Code,  DOR,  Sex,  DOB, 
Advisors_SSAN,  EntryJDate,--  DPhone,  HPhone, 
Locai_Address,  Foreign_Service_Ind ,  Service, 

Departure_Date,  SecurityjClearance,  Duty_Location, 
Aero_Rating,  Previous_MAJCOM,  Marital _Status ,  TMST, 
EthnicjGroup,  GRE,  GMAT,  DutyjTitle,  Section, 
Ac  ad  em  i c_S  t  and  ing . 

75.  STUDENT_AWARDS : 

SSAN*,  Award,  Date*. 

76.  STUDENTJUST: 

SSAN*,  Name,  Rank,  PAFSC,  Ed_Code,  Sex,  Entry_Date, 
Departure_Date,  Service,  Local_Address,  Address_Date , 
Aero_Rating,  Marital_Status ,  Ethnic_Group,  CRE,  GMAT, 
Degree  Code. 

81.  THESES: 

Thesis  No*,  Title,  Thesis_Sponsor ,  Classification, 
FirstJSuthor,  Second_Author"T  Subject,  Thesis_Pub_Date, 
OTIC  No,  Cleared_For  Release. 
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LOGICAL  DATABASE  VIEW  FOR: 


u 


Or 


RESOURCE  MANAGEMENT  DIRECTORATE,  BUDGET  £>  ACCOUNTING  (AFIT/ACB) 


AFIT_COURSES: 

Course*,  Title,  Description,  Min_Credit,  Max_Credit, 
Special_Grading,  Section_Control,  Remarks,  Lec_Hrs, 
Lab_llrs,  Student_Limit,  Special_R6om_Type . 

AFSC: 

AFSC*,  Description* 

ALLOWANCE_PAYMENTS : 

SSAN*,  Allowance_Ty pe* ,  Date__Paid*,  Amount. 

ALLOW ANCE/PAYMENT_TYPES : 

Allowance_Type* ,  Description. 

BOOK_ORDERS : 

Author,  Title,  Order_No* ,  No_Ordered,  Date,  Status. 
CI_DATA: 

SSAN*,  Program,  Output_AFSC,  Degree_Code,  PriorjGPA, 
Available_Date,  Prior_AFIT,  Departure_Reason, 

Suspense_Date ,  Legal_Residence ,  Thesis  Pay, 

Suspense__Action,  Status,  ¥egin_Date,  C_GPA,  TermJSPA. 

CI_PROGRAMS: 

Program*,  Description. 

COURSE_TIMES: 

Course*,  Starting_Time* ,  Day*,  Quarter*,  Year*,  Room, 
Building,  Course_Status ,  Wait_List_No,  Begin_Date, 
End_Da te • 

CURRENT_CI_PROGRAMS : 

Location_Code* ,  Program*,  POC,  DPhone. 

ED_HIST: 

SSAN*,  College*,  Begin_Date,  End_Date,  Degree_Code, 
Departure_Reason,  Remarks. 

EQUIPMENT: 

Stock_No*,  Description,  Price,  Date_Ordered* , 
Date  Received,  Availability,  Office. 

FOREICN_STUDENTS_DATA : 
lD_No*,  Service,  Country,  Funding. 

GRADES: 

SSAN*,  Course*,  Quarter*,  Year*,  Grade. 
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39.  I NS  TI TUT ION_POC  S : 

Location_Code*,  POC,  DPhone. 

AO.  INST_PAYMENTS : 

Location_Code* ,  Date*,  Payment_Type* ,  Amount. 

41.  LOCATIONS: 

Location_Code* ,  Location_Name ,  Local  Address. 

44.  MAJCOMS: 

MAJCOM* ,  MAJCOM_Tltle. 

46.  MED_PROCRAM: 

SSAN*,  MCAT_Score,  MCAT_Score_Date ,  Degree_Code, 

Med_Program,  Accesslon_Source . 

4b.  MMEP: 

Locatlon_Code* ,  Supporting  Inst_Code. 

50.  MMEP_FUNDINC: 

Location_Code*,  Fund_Type*,  No_Students. 

52.  OFFICES: 

Office*,  Office  Title. 


54.  PCE: 

Course*,  LocationjCode* ,  MAJCOM*,  Student_Limlt , 
No  Students. 


66.  SCHOOL/ EWI_DATA: 

Locatlon_Code* ,  Servlcing_AFO,  Tuition_Rate . 

74.  STUDENTS: 

SSAN*,  Name,  Rank,  PAFSC,  Ed_Code,  DOR,  Sex,  DOB, 
Advisors_SSAN,  Entry_Date,  DPhone,  HPhone, 
Local_Address,  Forelgn__Servlce_Ind,  Service, 

Departure_Date,  Security_Clearance,  Duty_Location, 
Aero_Rating,  Previous_MAJCOM,  Marital_Status,  TMST, 
Ethnic_Croup,  GRE,  GMAT,  Duty_Title,  Section, 
Academic  Standing. 


77.  STUDENT  PAYMENTS: 


SSAN*,  ESA_No* ,  Date*, 
80.  TDY: 

Destination*,  SSAN*, 
Estimated  Cost,  Actual 


Payment_Type* ,  Amount. 

Departure_Date* ,  Return_Date, 
Cost, Fees,  Per  Diem,  Travel. 
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LOGICAL  DATABASE  VIEW  FOR: 
EDUCATION  PLANS  &  OPERATIONS  (AFIT/ED) 


1.  ACADEHIC_TITLES: 

Academic_Title_Code* ,  Academic_Title. 

2.  AFITjCALENDAR: 

Day*\  Month*,  Year*,  Star ting_Time* ,  Activity, 
CC_Activity,  Room*,  Building*,  POC,  Remarks. 

3.  AFIT_COURSES: 

Course*,  Title,  Description,  Min_Credit,  Max_Credit, 
Special_Crading ,  Section_Control ,  Remarks,  Lec_Hrs, 
Lab_Hrs,  Student_Limit ,  Special_Room_Type . 


A. 

AFSC: 

AFSC* ,  Description. 

5. 

ALLOWANCE_PAYMENTS : 

SSAN*,  Allowance  Type*,  Date__Paid*,  Amount. 

6. 

ALLOW ANCE/PAYMENTJTYPES : 

Allowance_Type* ,  Description. 

7. 

AUDI0_VIS : 

Title*,  Time,  Producer*,  Speaker, 

Product ion_Date . 

Subject 

8. 

AWARDS : 

SSAN*,  Award,  Date*. 

9. 

BINDINGS: 

Title*,  Volume,  Month,  Year,  Color  No,  Lrtter 

Color. 

10. 

BOOKS: 

Title*,  Author*,  Publisher,  No_Avail,  Price, 

Office. 

11. 

B00K_0RDERS: 

Author,  Title,  Order_No*,  No_0rdered,  Date, 

Status . 

12. 

BOXES: 

SSAN*,  Box_No* . 

13. 

CHECKOUTS: 

Call  No*,  Patron_Name,  ID  No*,  Due  Date. 

1A. 

Cl  DATA: 

SSAN*,  Program,  Output_AFSC,  Degree_Code,  Prior_GPA, 
Available_Date ,  Prior_AFIT,  Depar ture_Reason , 
Suspense  Date,  Legal_Residence,  Thesis_Pay, 
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Suspense_Action,  Status,  Begin_Date,  CjGPA,  Term_GPA. 

15.  CI_PROGRAMS: 

Program*,  Description. 

16.  COURSE_BOOKS ; 

Course*,  Author*,  Title*,  No_Required,  Quarter*, 
Year* . 

17.  COURSE_TIMES: 

Course*,  Starting__Tlme* ,  Day*,  Quarter*,  Year*,  Room, 
Building,  Course_Status ,  Wa  i  t_L  i  s  t_No ,  Begin_Date, 
End  Date. 


18 .  CUR  RE NT_C  I_PR  OGRAM S : 

Location_Code* ,  Program*,  POC,  DPhone. 

19.  CURRENT_THESES : 

SSAN*,  Thesis_No,  Advlsors_SSAN,  Readerl,  Reader2. 

20.  DECREES: 

Degree_Code* ,  Description. 


21.  DECREE_SOUCHT: 

SSAN*,  DegreejCode,  Major,  Minor. 

22.  DE_DATA: 

SSAN*,  DAFSC,  Funct_Acct_Code ,  DOS,  Arri val_Date . 

23.  DUTY_OFFICER: 

SSAN*,  Duty,  Credit_Date,  Duty_Date. 

24.  EDjCODES: 

Ed_Code* ,  Ed_Code_Tl tie. 

25.  EDJ1IST: 

SSAN*,  College*,  Begin_Date,  End_Date,  Degree_Code, 
Depar ture_Reason ,  Remarks. 

26.  ED_PLANS: 

SSAN*,  Course*,  Quarter*,  Year*,  Credits. 


27.  EQUIPMENT: 

Stock_No*,  Description,  Price, 
Date_Received ,  Availability,  Office. 

28.  EXTRA_DUTIES: 

Extra  Duty  Code*,  Extra  Duty  Title. 


Date  Ordered*, 


29.  EXTRA__DUTY_ROSTER : 

SSAN*,  Extra  Duty  Code*,  Date. 
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30.  FAC_BOARD: 

SSAN*,  Trouble_Term,  Quarter*,  Year*,  Trouble_Year , 
Reason,  Initial_Analysis ,  Board_Ac tlon ,  Success, 
Remarks . 


31. 


32. 


33. 


FAC_BOARD_STUD_DATA : 

SSAN*,  Quarter*,  Year*,  UC_CGPA,  GRE,  CM  AT,  Terxn_GPA, 
C_GPA,  A_Cred,  BjCred,  C_Cred. 

FAC_COURSES: 

SSAN* ,  Course*,  Quarter*,  Year*,  Instructor_No, 
Croup  Contact  Hrs,  Ind  Contact  llrs. 


FACJED: 

SSAN*,  Primary  Ed_Level, 

Special  Interest. 


Secondary  Ed  Level, 


34.  KAC_REPLACEMENT: 

Pos_No*,  Office,  DAFSC,  Rank,  Name,  Arrival  Date, 
Degree_Required ,  Academic_Specialty ,  Status,  DPhone. 

35.  FAC_WORK: 

SSAN*,  Location*,  Rank*,  Regin_Date,  End__Date. 

36.  FOREICN_STUDENTS_DATA: 

ID_No*,  Service,  Country,  Funding. 

37.  CRADES: 

SSAN*,  Course*,  Quarter*,  Year*,  Grade. 

38.  HOLDINGS: 

Title*,  Office*,  Begin_Date,  End_Date. 

39.  INSTITUT I0N_P0CS : 

Location_Code* ,  POC,  DPhone. 

40.  INST_PAYMENTS: 

Location_Code* ,  Date*,  Payment  Type*,  Amount. 

41.  LOCATIONS: 

Location_Code* ,  Locatlon_Name ,  Local_Address . 

42.  LOCKERS: 

SSAN*,  Locke r_No*. 

43.  LIBRARY_BOOKS: 

Call_No*,  Title,  Author. 

44 .  MAJCOMS : 

MAJCOM* ,  MAJCOM  Title. 


45.  !1ED_B0ARD_CERTIF1CATI0N: 

SSAN*,  Med_Spec_Code*  ,  Certif ication_Oate ,  ANAT_Score, 
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46. 

47. 

4fl. 

49. 

50. 

51. 

52. 

53. 

54. 

55. 

56. 

57. 

58. 

59. 

60. 


PllYS_Score ,  BIOCH_Score,  PATH_Score,  MICR0_Score, 
PHARM_Score,  BEHSCI_Score ,  Score_Date. 

MED_PROCRAM : 

SSAN*,  MCAT_Score,  MCAT_Score_Date ,  Degree_Code, 

Med_Program,  Accession_Source . 

MED_T0URS: 

SSAN*,  Med_Spec_Code ,  Location^Code* ,  Begin_Date*, 

End  Date. 

MMEP: 

Location_Co‘de*  ,  Supporting_Inst_C  >de . 

MME  P_CLA  SSR00MS : 

Location_Code* ,  Room*,  Building*. 

MMEP_FUNDINC: 

Location_Code* ,  Fund_Type*,  No_Students. 

N0N_STU DENTS: 

Name,  Card_No*,  Organization,  DPhone. 

OFFICES: 

Office*,  Of f ice_Title . 

PAST_COURSES: 

SSAN*,  College*,  Course*,  Crade,  Quarter*,  Year*. 

PCE: 

Course*,  Location_Code* ,  MAJCOM*,  Student_Limit , 
No_Students . 

PREREQUISITES: 

Course*,  Prerequisite*. 

PRESENTATIONS: 

SSAN*,  Date*,  Title,  Location,  Organization*,  Subject. 

PROFESS I0NAL_0RGS: 

Org_Abbrev* ,  0rg_Name . 

PR0F_FAC_0RCS : 

SSAN*,  0rg_Abbrev*. 

PR  ONOT I ON_S  TATS: 

BoardJDate*,  BoardJUnd* ,  USAF,  AFIT,  USAF_Elig, 
AFIT_Elig. 

PUBLICATIONS: 

SSAN*,  Title*,  Date,  Subject,  Source*,  Location, 
Pub  Kind,  Co  Auth  Name. 
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1  0* 

- 

* 


61. 

62. 

63. 


64. 

65. 


66. 

67. 


68. 


69. 


70. 


71. 


72. 

73. 


74. 


QUOTAS; 

Ed_Code* ,  QuotaJType*,  YRl ,  YR2,  YR3,  YR4,  YR5. 
RESERVES: 

Call_No*,  FAC_SSAN*,  Da te_Re served* . 

RESIDE  NT_DATA : 

SSAN*,  Last_Organization,  Duration,  DOC, 

Emergency_Address. 

ROOMS : 

Room*,  Building*,  Max_Size,  Special_Room_Type . 

ROOM_S  CHEDULE : 

Day*,  Month*,  Year*,  Star ting_Time* ,  Ending_Time, 
Room,  Building*,  Function. 

SCHOOL/EWI_DATA: 

Location_Code* ,  Servicing_AFO,  Tuition_Rate . 

SECTION; 

Section*,  Graduation_Date ,  Entry_Date,  No_Students, 
Leader_SSAN,  Advisors_SSAN,  Non_AF. 

SU0RT_C0URSE: 

Course*,  Title,  Begin_Date*»  End_Date,  Room*,  Build¬ 
ing*,  Starting_Time,  Description. 

SU0RT_STU DENTS : 

SSAN*,  Course*,  Begin_Date*,  Name,  Rank.,  Organization, 
DPhone 

SPOUSES: 

Sponsors_SSAN* ,  Name,  DOB,  No_Deps,  Spouse_Type, 
Military_Spouse . 

STAFF : 

SSAN*,  Name,  Rank,  HPhone,  DPhone,  Room,  Office, 
Po8_No,  Duty_Title,  Da te__As signed  ,  Departure_Date , 
Local_Address ,  DOB,  DOR,  Acad_Title_Code,  DOAR, 
Marital_Status ,  Sex,  PAFSC,  DAFSC,  Ethnic_Croup ,  Ser¬ 
vice,  Photo_Date,  Secur ity_Clearance ,  TMST, 
P  r  e v i o  u  s_MA J COM. 

STAFF  DE  DATA: 

SSAtf*-,  7ourse_Directed* . 

STAFF_POSITION_DATA : 

Pos_No*,  SSAN,  Ed_Code_Requi red ,  Ed_Code_As signed , 
Degree_Level_Required ,  Degree_Level_Assigned . 

STUDENTS: 

SSAN*,  Name,  Rank,  PAFSC,  Ed_Code,  DOR,  Sex,  DOB, 
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Advisors_SSAN,  Entry_Date,  DPhone,  HPhone, 
Local_Addres8,  Foreign_Service_Ind,  Service, 

Departure_Date ,  Security_Clearance,  Duty_Location, 
Aero_RaCing,  Previous_MAJCOM ,  Marita]  Status,  TMST, 
Ethnic_Croup,  GRE,  GMAT,  Duty_Titie,  Section, 
Academic_Standing . 

75.  STUDENT_AWARDS : 

SSAN* ,  Award,  Date*. 

76.  STUDENTJ1IST: 

SSAN*,  Name,  Rank,  PAFSC,  Ed_Code,  Sex,  Entry_Date, 
De par ture_D'a  te  ,  Service,  Local  Address,  Address  Date 
Aero_Rating,  Marital_Status ,  Ethnic_Group,  GRE,  GMAT, 
Degree_Code . 

77.  STUDENT_PAYMENTS: 

SSAN*,  ESA_No* ,  Date*,  Payment_Type* ,  Amount. 

78.  STUDENT_SCHED: 

SSAN*,  Course*. 

79.  SUBSCRIPTIONS: 

Title*,  Check_In,  Renewal_Date ,  Price, 

Expiration_Date,  Requester,  Begin_Date, 

Follow_Up_Date ,  Follow_Up_Remarks . 

80.  TDY: 

Destination*,  SSAN*,  Departure_Date* ,  Return_Date, 
Estimated_Cost ,  Ac tual_Cost , Fees ,  Per_Diem,  Travel. 

81.  THESES: 

Thesis_No*,  Title,  Thesis_J>ponsor ,  Classification, 
First_Author ,  Second_Author ,  Subject,  Thesis_Pub_Date , 
DTIC  No,  Cleared  For  Release. 


82.  TUESIS_SP0NS0RS: 

Thesis  Sponsor*,  Location. 


RELATIONS  PERTAINING  TO  THE 

REGISTRARS 

INFORMATION 

83. 

COURSE  GRADES: 

SSAN*,  Course*, 

Grade  Type , 

Grade , 

Prior  Grade 

Registered  Hrs, 

Earned  llrs, 

Qual  Pt:>, 

Drop  Reason 

Date . 

84. 

COURSE  STATS: 

Course*,  Proj  Enrollment,  Min 

Enrollment , 

No  Enrolled 

Demand,  Drops,  Wait_Llst  No,  No_Not_Registered , 
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No  Added,  No  Audits 


85.  GMAT_SCORES: 

SSAN* ,  Total. 


86.  CRE_SCORES: 

SSAN* ,  Verbal,  Quantitative,  Total. 


87.  RR  DATA: 

SSAN*,  Manning_Code,  Output_MAJCOM ,  UG_CGPA, 
Degree_Code,  Prior_AFlT,  Folder__Location, 
Departure  Reason,  Admission_Action ,  Transfer_Ind , 
Prev_CPA,  C_GPA,  GRE_Ind ,  GMAT_Ind,  Re_Admit_Term, 
Academic_Elig ,  Calc_Required_Term,  Degree_Checkout , 
Admin  Hold,  Re  Admit  Year,  Calc  Required  Year. 


88. 


TRANSFERS: 

SSAN*,  Location_Code* ,  TRF_Hrs, 
TRF_Qual_Pts ,  Begin_Date,  Quarter, 
TRF  End  Date,  Old  Code. 


TRF_Qual_Hrs, 
TRF  In  Date, 
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LOGICAL  DATABASE  VIEW  FOR: 


SCHOOL  OF  SYSTEMS  &  LOCISTICS  (AFIT/LS) 


1.  ACADEMIC_TITLES : 

Academic_Ti tlejCode*,  Acad  era  ic_Ti  tie. 

2.  AFIT_CALENDAR: 

Day*,  Month*,  Year*,  Starting_Time* ,  Activity 
CC_Activity,  Room*,  Building*,  POC,  Remarks. 

3.  AFIT_COURSES : 

Course*,  Title,  Description,  Min_Credit,  Max_Credit 
Special_Crad ing ,  Section_Control ,  Remarks,  Lec_Hrs 
Lab  Hrs,  Student  Limit,  Special  Room  Type. 


4. 

AFSC: 

AFSC*,  Description. 

5. 

ALLOWANCE_PAYMENTS : 

SSAN*,  Allowance_Type* ,  Date  Paid*,  Amount. 

6. 

ALLOWANCE/ PAYMENT_T  YPES : 

Allowance  Type*,  Description. 

8. 

AWARDS : 

SSAN*,  Award,  Date*. 

10, 

BOOKS : 

Title*,  Author*,  Publisher,  No  Avail, 

Price,  Office. 

11. 

B00K_0RDERS: 

Author,  Title,  Order  No*,  No  Ordered, 

Date,  Status. 

12. 

BOXES: 

SSAN*,  Box_No*. 

16. 

COURSE  BOOKS: 

Course*,  Author*,  Title*,  No_Required,  Quarter* 
Year*. 

17.  C0URSE_T1MES: 

Course*,  Star ting_Tirae* ,  Day*,  Quarter*,  Year*,  Room 
Building,  Course_Stutus ,  Wait_List_No ,  Begin__Date 
End_Date. 

19.  CURRENT_THESES : 

SSAN*,  Thesis  No,  Advisors  SSAN,  Readerl,  Reader2. 
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21.  DECREE_SOUGHT: 

SSAN*,  Degree_Code,  Major,  Minor. 

24.  ED_CODES: 

Ed  Code*,  Ed  Code  Title. 


25.  ED_HIST: 

SSAN*,  College*,  Begin_Date,  End_Date,  Degree__Code , 
Departure  Reason,  Remarks. 


26.  ED_PLANS: 

SSAN*,  Course*,  Quarter*,  Year*,  Credits. 


27.  EQUIPMENT: 

Stock_No*,  Description,  Price,  Date_Ordered* , 
Date_Received ,  Availability,  Office. 


28. 

29. 


EXTRAJDUTIES: 

Extra_Duty_Code* ,  Extra_DutyJTitle . 

EXTRA  DUTY_ROSTER: 

SSAN*  Extra  Duty  Code*,  Date. 


30.  FAC  BOARD: 

SSAN*,  TroubleTerm,  Quarter*,  Year*,  TroubleYear , 
Reason,  Initial_Analysis,  Board_Action,  Success, 
Remarks. 

3 1 .  FAC_BOARD_STUD_DATA : 

SSAN*,  Quarter*,  Year*,  UC_CCPA,  CRE,  CM AT,  Term_GPA, 
CGPA,  AjCred,  B_Cred,  C_Cred . 

32.  FACjCOURSES: 

SSAN*,  Course*,  Quarter*,  Year*,  lnstructor_No , 
Croup  Con tact_Hrs,  Ind_Contact_Hr s. 

33.  FACED: 

SSAN*,  Pr imary_Ed_Leve 1 ,  Second ary_Ed_Level , 

Special_Intere8t . 

34.  FAC_REPLACEMENT: 

Po8_No*,  Office,  DAFSC,  Rank,  Name,  Arr ival_Date , 
Degree_Required ,  Academic_Special ty ,  Status,  DPhone. 

35.  FAC_W0RK: 

SSAN*,  Location*,  Rank*,  Begin  Date,  End  Dace. 


36. 

37. 


FOREICN_STUDKNTS_DATA : 
lD_No*,  Service,  Country,  Funding. 

GRADES: 

SSAN*,  Course*,  Quarter*,  Year*,  Grade. 
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41. 

42. 

44. 

32. 

53. 

54. 

55. 

56. 

57. 

58. 

60. 

63. 

64. 

65. 

67. 

68. 


LOCATIONS: 

Location_Code* ,  Location_Name ,  Local_Address . 

LOCKERS: 

SSAN*,  Locke r_No*. 

MAJCOMS: 

MAJCOM* ,  MAJCOM_Title. 

OFFICES: 

Office*,  Of f ice_Ti tie. 

PAST_COURSES': 

SSAN*,  College*,  Course*,  Crade,  Quarter*,  Year*. 

PCE: 

Course*,  Location_Code* ,  MAJCOM*,  Student_Limit , 
No_Students . 

PREREQUISITES: 

Course*,  Prerequisite*. 

PRESENTATIONS : 

SSAN*,  Date*,  Title,  Location,  Organization*,  Subject. 

PROFESS IONALJDRGS : 

Org_Abbrev* ,  Org_Name . 

PROF_FAC_ORGS : 

SSAN*,  Org_Abbrev*. 

PUBLICATIONS: 

SSAN*,  Title*,  Date,  Subject,  Source*,  Location, 
Pub_Klnd ,  Co_Au th_Name . 

RESIDE  NT_DATA : 

SSAN*,  Last_Organization,  Duration,  DOC, 

Emergency_Addresa . 

ROOMS: 

Room*,  Building*,  Max_Size,  Special_Room_Type . 
R00M_SCI1EDULE : 

Day*,  Month*,  Year*,  Start ing_Time* ,  EndingJFirae, 
Room,  Building*,  Function. 

SECTION: 

Section*,  Graduation_Date,  Entry_Date,  No  Students, 
Leader_SSAN,  Advisors_SSAN,  Non_AF. 

S110RT_C0URSE: 

Course*,  Title,  Begin_Date*,  End_Date,  Room*,  Build¬ 
ing*,  Starting  Time,  Description. 
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69.  SHORT_STUDENTS: 

SSAN*,  Course*,  Begin_Date*,  Name,  Rank,  Organization, 
DPhone 

70.  SPOUSES: 

Sponsors_SSAN* ,  Name,  DOB,  No_Deps,  Spouse  Type, 
Military_Spouse.  ~  ' 

7 1 .  STAFF : 

SSAN*,  Name,  Rank,  HPhone,  DPhone,  Room,  Office, 
Pos_No,  Duty_Title,  Date_Assigned ,  Departure_Date , 
Local_Address ,  DOB,  DOR,  Acad_Title_Code,  DOAR, 
Marital_Status,  Sex,  PAFSC,  DAFSC,  Ethnic_Group,  Ser¬ 
vice,  Photo_Date,  Security_Clearance,  TMST, 
Pr ev i ou  s_MAJC0M . 

7  3 .  STAFF_POS IT I0N_DATA : 

Pos_No*,  SSAN,  Ed_Code_Required ,  Ed_Code  Assigned, 
Degree_Level_Required ,  Degree_Level  Assigned. 

74.  STUDENTS: 

SSAN*,  Name,  Rank,  PAFSC,  Ed_Code,  DOR,  Sex,  DOB, 
Advisors_SSAN,  Entry_Date,  DPhone,  HPhone, 
Local_Address ,  Foreign_Service_Ind ,  Service, 

Departure_Date ,  SecurityJElearance,  Duty_Location, 
Aero_Rating,  Previous_MAJCOM,  Marital_Status ,  TMST, 
EthnicjGroup,  GRE,  CHAT,  Duty_Title,  Section, 
Academic_Standing . 

75.  STUDENT_AWARDS : 

SSAN*,  Award,  Date*. 

76.  STUDENTJ1IST: 

SSAN*,  Name,  Rank,  PAFSC,  Ed_Code,  Sex,  Entry_Date, 
Departure_Date,  Service,  Local_Address ,  Address_Date , 
Aero_Rating,  MaritaI_Status ,  Ethnic_Croup,  CRE,  CHAT, 
Degree_Code. 

78.  STUDENT_SCHED: 

SSAN*,  Course*. 

80.  TDY: 

Destination*,  SSAN*,  Depar ture_Date* ,  Return_Date, 

Estimated_Cost ,  Actual_Cost , Fees ,  Per_Diem,  Travel. 

81.  THESES: 

Thesis_No*,  Title,  Thesis_Sponsor ,  Classif ication , 
Fi rst_Author ,  Second_Author ,  Subject,  Thesis_Pub_Date , 
DTIC_No,  Clearcd_For_Relea.se. 

82.  TIIESIS_SPONSORS : 

Thesis  Sponsor*,  Location. 
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RELATIONS  PERTAINING  TO  THE  REGISTRARS  INFORMATION 


83.  COURSE_CRADES : 

SSAN*,  Course*,  Crade_Type,  Grade,  Prlor_Grade 
Regiscered_Hrs,  Earned_Hrs,  Qual_Pts,  Drop_Reason 
Da  te . 

84.  COURSE_STATS: 

Course*,  Pro j__Enrollment ,  Min_Enrollment,  No_Enrolled 
Demand,  "Drops,  Wait_List_No ,  No_Not_Registered 
No_Added ,  No_Aud Its . 

85.  CMAT_SCORES: 

SSAN* ,  Total. 

86.  CRE_SCORES: 

SSAN*,  Verbal,  Quantitative,  Total. 
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LOGICAL  DATABASE  VIEW  FOR: 
SCHOOL  OF  ENGINEERING  (AFIT/EN) 


1.  ACADEMIC_TITLES: 

Acaderaic_Title_Code* ,  Academic_Title. 

2.  AF IT_C ALE  NDAR : 

Day*,  Month*,  Year*,  Starting_Time* ,  Activity 
CC_Activity,  Room*,  Building*,  POC,  Remarks. 

3.  AFITjCOURSES: 

Course*,  Title,  Description,  Min_Credit,  Max_Credit 
Special_Crad ing ,  Section_Control ,  Remarks,  Lec_Hrs 
Lab_Hrs,  Student_Limit ,  Special_Room_Type . 

4.  AFSC: 

AFSC* ,  Description. 

5.  ALLOWANCE_PAYMENTS : 

SSAN*.  Allowance_Type* ,  Date_Paid*,  Amount. 

b .  ALLOWANCE/PA YMENT_TYPES : 

Allowance_Type* ,  Description. 

7.  AUDIO_VIS: 

Title*,  Time,  Producer*,  Speaker,  Subject 
Produc tion_Date . 

B.  AWARDS: 

SSAN*,  Award,  Date*. 

10.  BOOKS: 

Title*,  Author*,  Publisher,  No_Avail,  Price,  Office. 

11.  B00K_0RDERS : 

Author,  Title,  Order_No*,  No_0rdered,  Date,  Status. 

12.  BOXES: 

SSAN*,  Box_No*. 

16.  COURSF.JIOOKS : 

Course*,  Author*,  Title*,  No_Required,  Quarter* 
Year*. 

17.  COURSE_TIMES; 

Course*,  Star ting_Time* ,  Day*,  Quarter*,  Year*,  Room 
Building,  Cour se_Status ,  Wa it_Li st_No ,  Begin_Date 
End_Date . 

19.  CURRENT  THESES: 
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20. 


SSAN* ,  Thesis_No,  Advisors_SSAN,  Readerl,  Reader2. 
DEGREES: 

DegreejCode*,  Description. 


21.  DECREE__S0UCUT: 

SSAN*,  Degrce_Code,  Major,  Minor. 

24.  ED_C0DES : 

Ed_Code* ,  Ed  Code  Title. 


25.  ED_HIST: 

SSAN*,  College*,  Begin_Date,  End_Date,  Degree  Code, 
Departure_Reason,  Remarks. 


26.  ED_PLANS: 

SSAN*,  Course*,  Quarter*,  Year*,  Credits. 


27.  EQUIPMENT: 

Stock_No*,  Description,  Price,  Date_0rdered* , 
Date_Received ,  Availability,  Office. 


28.  EXTRA_DUTIES: 

Extra_Duty_Code* ,  Extra_Duty  Title. 


29 .  EXTRA_DUT  Y_ROSTER : 

SSAN*,  Extra_Duty_Code* ,  Date. 


30.  FAC_B0ARD: 

SSAN*,  Trouble_Term,  Quarter*,  Year*,  Trouble_Year , 
Reason,  Initial_Analysis,  Board_Action,  Success, 
Remarks. 


3 1 .  FAC_BOARD_STUD_DATA : 

SSAN*,  Quarter*,  Year*,  UG_CGPA,  GRE,  GMAT,  Term  GPA, 
C_GPA,  A  Cred,  B  Cred,  C  Cred. 


32.  FAC_COURSES: 

SSAN*,  Course*,  Quarter*,  Year*,  Instruc tor_No , 
Group  Contact  Hrs,  Ind  Contact  Hrs. 


33.  FAC_ED: 

SSAN*,  Primary_Ed_Level ,  Secondary_Ed_Level , 

Special  Interest. 


34.  FAC_REPLACEMENT: 

Pos_No*,  Office,  DAFSC,  Rank,  Name,  Arrival  Date, 
Degree_Required ,  Academic_Special ty ,  Status,  DPhone. 


35.  FAC_W0RK: 

SSAN*,  Location*,  Rank*,  Begin  Date,  End  Date. 
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Qjr 


36. 

37. 

41. 

42. 

44. 

52. 

53. 

54. 

55. 

56. 

57. 

58. 

60. 

63. 

64. 

65. 

67. 


FORE ICNJSTUDE  NTS_DATA : 

ID_No*,  Service,  Country,  Funding. 

CRADES: 

SSAN*,  Course*,  Quarter*,  Year*,  Crade. 

LOCATIONS : 

Location_Code* ,  Location_Name ,  Local_Address . 

LOCKERS: 

SSAN* ,  Locke  r_No* . 

MAJCOMS: 

MAJCOM* ,  MAJCOMJT 1 1 1 e . 

OFFICES: 

Office*,  Of f ice_Tltle. 

PAST_COURSES: 

SSAN*,  College*,  Course*,  Crade,  Quarter*.  Year*. 

PCE: 

Course*,  Location_Code* ,  MAJCOM*,  Student_Limit , 

No_Students. 

PREREQUISITES: 

Course*,  Prerequisite*. 

PRESENTATIONS: 

SSAN*,  Date*,  Title,  Location,  Organization*,  Subject. 

PROFESSIONAL_ORGS : 

Org_Abbrev*,  OrgJName. 

PROF_FAC_ORCS : 

SSAN*,  Org_Abbrev*. 

PUBLICATIONS: 

SSAN*,  Title*,  Date,  Subject,  Source*,  Location, 
Pub_Klnd ,  Co_Au th_Name . 

RESIDE NT_DATA: 

SSAN*,  Last_Organizatlon,  Duration,  DOC, 

Emergency_Address. 

ROOMS: 

Room*,  Building*,  Max_Slze,  Special_Room_Type . 
ROOM_SCHEDULE : 

Day*,  Month*,  Year*,  Starting  Time*,  Ending_Time, 
Room,  Building*,  Function. 

SECTION: 
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Section*,  Graduation_Date ,  Entry_Date,  No_Students, 
Leader_SSAN,  Advisors_SSAN,  Non_AF. 

68.  SHORT_COURSE: 

Course*,  Title,  Begin_Date*,  End_Date,  Room*,  Build¬ 
ing*,  Starting_Time,  Description. 

69.  SHORT_STUDENTS : 

SSAN*,  Course*,  Begin_Date*,  Name,  Rank,  Organization, 
DPhone 

70.  SPOUSES: 

Sponsors_SSAN* ,  Name,  DOB,  No_Deps,  Spouse_Type, 
Military  Spouse. 

71.  STAFF: 

SSAN*,  Name,  Rank,  HPhone,  DPhone,  Room,  Office, 
Pos_No,  Duty_Title,  Da  te__As  signed ,  Departure_Date , 
Local_Address ,  DOB,  DOR,  Acad_Title__Code,  DOAR, 
Marital_Status ,  Sex,  PAFSC,  DAFSC,  Ethnic__Croup,  Ser¬ 
vice,  Photo_Date,  Secur ity_Clearance,  TMST, 
Previous_MAJCOM . 

7  3 .  STAFF_POS  ITIONJDATA : 

Pos_No* ,  SSAN,  Ed_Code_Required ,  Ed_Code_Assigned , 
Degree_Level_Required ,  Degree_Level_Assigned . 

74.  STUDENTS: 

SSAN*,  Name,  Rank,  PAFSC,  Ed_Code,  DOR,  Sex,  DOB, 
Advisors_SSAN,  Entry_Date,  DPhone,  UPhone, 

Local_Address ,  Foreign_Serv ice_lnd ,  Service, 

Departure_Date ,  Security_Clearance,  Duty_Location, 
Aero_Rating,  Previous_MAJCOM,  Marital_Status ,  TMST, 
Ethnic_Croup,  CRE,  CMAT,  Duf.y_Title,  Section, 
Academic  Standing. 

75.  STUDENT_AWARDS : 

SSAN*,  Award,  Date*. 

76.  STUDENTJ1IST: 

SSAN*,  Name,  Rank,  PAFSC,  Ed_Code,  Sex,  Entry_Date, 
Departure_Date ,  Service,  Local_Address ,  Address_Date , 
Aero_Rating,  Marital_Status ,  Ethnic_Group,  CRE,  CMAT, 
Degree_Code . 

78.  STUDi:NT_SCHED: 

SSAN*,  Course*. 

80.  TDY: 

Destination*,  SSAN*,  Depa rture_Date* ,  Return_Date, 
Es timated_Cost ,  Ac tual_Cost , Fees ,  Per_Diem,  Travel. 

81.  THESES: 
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Thesis_No*,  Title,  Thesis_Sponsor , 
First_Author ,  Second_Author ,  Subject, 
DTIC  No,  Cleared  For  Release. 


Classification 
Thesis  Pub  Date 


82.  THESIS  SPONSORS: 

Thesis  Sponsor*,  Location. 


RELATIONS  PERTAININC  TO  THE  REGISTRARS  INFORMATION 


83.  COURSE_CRADES: 

SSAN*,  Course*,  Crade_Type,  Crade,  Prior__Crade 
Registered_llrs ,  Earned_Hrs,  Qual__Pts,  Drop__Reason 
Date . 

84.  COURSE  STATS: 

Course*,  Pro j_Enrollment ,  MinEnrollment ,  No_Enrolled 
Demand,  Drops,  Wait_List_No ,  No_Not_Registered 
No  Added ,  NoAud its. 

85.  CMATSCORES: 

SSAN*,  Total. 

86.  CRE  SCORES: 

SSAN*,  Verbal,  Quantitative,  Total. 
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AD-A124  647  ANALYSIS  OF  INFORMATION  REQUIREMENTS  AND  DESIGN  OF  THE  3/4 
CONSOLIDATED  AFIT  D.  .  (U)  AIR  FORCE  INST  OF  TECH 
NRIGHT-PATTERSON  RFB  OH  SCHOOL  OF  ENGI.  . 

UNCLASSIFIED  J  S  RICKS  ET  AL.  DEC  82  AFIT/GCS/EE/82D-11  F/G  5/2  NL 


LOCICAL  DATABASE  VIEW  FOR: 
AFIT  BOOKSTORE 


2.  AFIT  CALENDAR: 

Day*,  Month*,  Year*,  Starting  Time*,  Activity 
CC  Activity,  Room*,  Building*,  POQ,  Remarks. 

10.  BOOKS: 

Title*,  Author*,  Publisher,  No  Avail,  Price,  Office. 

11.  BOOK  ORDERS: 

Author,  Title,  Order  No*,  No  Ordered,  Date,  Status. 
16.  COURSE  BOOKS: 

Course*,  Author*,  Title*,  No_Required,  Quarter* 
Year* . 

27.  EQUIPMENT: 

Stock  No*,  Description,  Price,  Date  Ordered* 
Date  Received,  Availability,  Office. 

32.  FAC  COURSES: 

SSAN* ,  Course*,  Quarter*,  Year*,  Instructor  No 
Croup  Contact  Urs,  Ind  Contact  Hrs. 
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LOGICAL  DATABASE  VIEW  FOR: 


1. 

2. 

4. 

8. 

19. 

27. 

32. 

33. 

34. 

35. 

44. 

52. 

56. 

57. 

Appendix 


PROFESSIONAL  DEVELOPMENT  (AFIT/NR) 


ACADEMICTITLES: 

Academic  Title  Code*,  Acaderaic_Titl«? . 

AFIT  CALENDAR: 

Day*,  Month*,  Year*,  Starting  Time*,  Activity 
CC  Activity,  Room*,  Building*,  POC,  Remarks. 

AFSC : 

AFSC* ,  Description. 

AWARDS : 

SSAN*,  Award,  Date*. 

CURRENT  THESES: 

SSAN*,  Thesis_No,  Advisors_SSAN,  Readerl,  Reader  2 
EQUIPMENT: 

Stock  No*,  Description,  Price,  Date_Ordered* 
Date_Received ,  Availability,  Office. 

FAC_COURSES: 

SSAN*,  Course*,  Quarter*,  Year*,  Instruc tor_No 
Cronp_Contact_l  i-s,  Ind_Contact_lirs. 

FAC_ED: 

SSAN*,  Primary_Ed_Level,  Secondary_Ed_Level 
Special_Interest . 

FAC_REPLACEMENT: 

Pos_No*,  Office,  DAFSC,  Rank,  Name,  Arrival_Date 
Degree_Required ,  Academic_Specialty ,  Status 
DPhone . 

FAC_WORK: 

SSAN*,  Location*,  Rank*,  Begin_Date,  End_Date. 
MAJCOMS: 

MAJCOM* ,  MA JCOM_T i t 1 e . 

OFFICES: 

Office*,  Of fice_Title. 

PRESENTATIONS: 

SSAN*,  Date*,  Title,  Location,  Organization*,  Sub¬ 
ject. 

PROFESSIONAL  ORCS: 
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Org_Abbrev* ,  Org_Name . 

58.  PROF_FAC_ORCS : 

SSAN* ,  Org_Abbrev*. 

59.  PROMOTIONS  TATS: 

Board_Date* ,  BoardJCind*,  USAF,  AFIT,  USAF_Elig, 
AFIT_Elig. 

60.  PUBLICATIONS: 

SSAN*,  Title*,  Date,  Subject,  Source*,  Location, 
Pub_Klnd,  Co_Auth_Name . 

64.  ROOMS: 

Room*,  Building*,  Max_Size,  Special_Room_Type . 

65.  ROOM_SCl!EDULE : 

Day*,  Month*,  Year*,  Startlng_Time*,  Endlng_Tlme, 
Room,  Building*,  Function. 

70.  SPOUSES: 

Sponsors_SSAN*,  Name,  DOB,  No_Depa,  Spouse_Type, 
Ml 1 1  tar  y~Spouse . 

71.  STAFF: 

SSAN*,  Name,  Rank,  HPhone,  DPhone,  Room,  Office, 
Pos__No,  Duty_Title,  Da te_As signed  ,  Departure_Date, 
Local_Address ,  DOB,  DOR,  Acad_Tltle_Code,  DOAR, 
Marital_Status,  Sex,  PAFSC,  DAFSC,  EthnicjGroup, 
Service,  Photo_Date,  Secur lty_Clearance,  TMST, 
Previou8_MAJC0M.  \ 

73.  STAF  F_P0S I T 1 0N_DA  TA : 

Po8_No*,  SSAN,  EdjCodeJRequired ,  Ed_Code_As signed , 
Degrec_Level_Required ,  Degree_Level__Assigned . 

80.  TDY: 

Destination*,  SSAN*,  Departure_Date*,  Return_Date, 
EstimatedjCoat,  Ac tual_Cost ,Fees,  Per_Diem, 

Travel. 

81.  THESES: 

Thesis_No*,  Title,  Thesis_Sponsor,  Classification, 
First_Author ,  Second_Author ,  Subject, 

Thesis  Pub  Date,  DTIC  No,  Cleared_For_Release . 


82.  T11ESIS_SP0NS0RS: 

Thesis  Sponsor*,  Location. 
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RELATION 

QTY 

ESTIMATION  FACTORS  QTY  SOURCE 

1 

12 

CONSTANT 

SE 

2 

2400 

10/day  *  5  days/wk  *  12  wks/qtr  *  4  qtr/yr 
(see  note  1) 

AE 

3 

563 

Total  resident  courses  in  the  AFIT  catalog; 
CONSTANT 

AC 

4 

549 

MPC  AFSCs;  CONSTANT 

AC 

5 

931 

AFIT/EN  only;  CONSTANT 

SE 

6 

6 

3/EN  +  3 /Cl;  CONSTANT 

SE 

7 

250 

CONSTANT 

SE 

8 

250 

CONSTANT 

AE 

9 

2000 

CONSTANT 

SE 

10 

20000 

200  courses/qtr  *  25  books/course  *  4  qtr/yr 

AE 

11 

800 

1/course  *  200  courses/qtr  *  4  qtr/yr 

AE 

12 

1013 

EN  &  LS  only;  CONSTANT 

AC 

13 

500 

Daily  average  from  LD;  CONSTANT 

SE 

14 

4058 

All  Cl  students  listed  on  the  8  Sep  82  SAR; 
CONSTANT 

SE 

15 

2400 

400  institutions  *  6  programs/institution 
CONSTANT 

SE 

16 

1600 

2  books/course  *  200  courses/qtr  *  4  qtr/yr 

AE 

17 

1600 

2  times/course  *  200  courses/qtr  *  4qtr/yr 

AE 

18 

121 

Cl  catalog;  CONSTANT 

AC 

19 

500 

CONSTANT 

AE 

20 

500 

CONSTANT 

AE 

21 

5200 

1063  EN  &  LS  students  +  4058  Cl  students  +  ROF; 
Sep  82  SAR;  CONSTANT 

SE 

22 

2140 

2096  DE  students  +  40  DE  staff  +  ROF;  CONSTANT 

SE 

23 

134 

CONSTANT  ' 

SE 

24 

100 

CONSTANT 

SE 

25 

1000 

995  EN  &  LS  resident  students  +  ROF;  CONSTANT; 
(Note:  Part  time  students  not  counted); 

8  Sep  82  SAR 

SE 

26 

20000 

1000  EN  &  LS  students  *  20  entries/student; 
CONSTANT 

AE 

27 

500 

CONSTANT 

AE 

28 

255 

DA  duty  roster;  CONSTANT 

AC 

29 

270 

DA  duty  roster;  CONSTANT 

AC 

30 

100 

CONSTANT 

SE 

31 

250 

100/year  *  2.5/student;  CONSTANT 

SE 

32 

2700 

225  EN,  LS  4  DE  faculty  (includes  ROF)  *  3 
courses  per  faculty/qtr  *  4  qtr/yr 

SE 

33 

225 

225  Total  faculty  (includes  ROF);  CONSTANT 

SE 

34 

25 

CONSTANT 

AE 

35 

1800 

225  faculty  members  *  8/faculty  member 

CONSTANT 

SE 

36 

34 

8  Sep  82  SAR;  CONSTANT 

SE 

37 

16000 

1000  resident  students  *  4  courses/student 
*  4  qtrs/yr 

AE 

38 

1000 

CONSTANT 

SE 

39 

400 

1/lnstitute  *  400  institutes;  CONSTANT 

SE 

Appendix  18 

PACE  i 

2400  400  institutes  *  6/institute;  CONSTANT  SE 

40000  CONSTANT  AE 

795  CONSTANT  AC 

81320  80000  books  with  call  no.s  +  (110  new  books/mo.  SE 

*  12  mo . / yr . ) 

14  CONSTANT  AE 

1000  (440  CIM  students+ROF)  *2  Med  Certifications/  SE 

student;  8  Sep  82  SAR;  CONSTANT 
1867  440  CIM  students  +  1427  AFI1PSP  students;  SE 

8  Sep  82  SAR;  CONSTANT 

5600  (440  CIM  students  +  1427  HPSP  students)  *  AE 

3  tours/student;  CONSTANT 

6  '  CONSTANT  SE 

10  CONSTANT  AE 

24  6  MMEP  programs  *  4  fund  types/ program  Z 

700  CONSTANT  SE 

100  AFIT  Staff  Directory,  Oct  81;  CONSTANT  AC 

-—**  NOT  INCLUDED  IN  ESTIMATION  AE 

128  AFIT  catalog  (LS  +  DE  +  EN  +  PCE  courses);  AC 


CONSTANT 

1029  ((563  resid.  courses  *  80Z  with  prerequisites)  AE 

*  2  prerequisites/course)  +  ((128  PCE  courses  * 


50  Z  with  prerequisites)  *  2  prerequisites/ 
course)  +  ROF 

2700  225  faculty  members  *  3/member/qtr  *  4  qtr/yr  AE 

200  CONSTANT  SE 

1125  225  faculty  members  *  5/person;  CONSTANT  SE 

100  CONSTANT  AE 

675  225  faculty  members  *  3/person;  CONSTANT  AE 

200  (100  quotas  (1/ED  Code))  *  2  types  of  quotas;  SE 

CONSTANT 

3000  CONSTANT  SE 

1000  995  resident  students  +  ROF;  CONSTANT  SE 

130  LS  +  EN  +  Bldg  125  schedulable  rooms  +  ROF;  AC 

CONSTANT 

135200  130  rooms  *  4  events/room/day  *  260  school  AE 

days/yr;  CONSTANT 

475  400  schools  +75  EWI  locations;  CONSTANT  SE 

52  CONSTANT  SE 

128  AFIT  catalog;  EN  +  LS  +  DE  PCE  courses;  AC 

CONSTANT 

13000  2096  DE  ('82)  +  9000  I.S  ('S3)  +  1800  EN  ('82)  SE 

+  ROF;  CONSTANT 

1000  CONSTANT  AE 

578  All  staff  listed  on  8  Sep  82  SAR;  CONSTANT  SE 

30  30  courses  *  1  director/course;  CONSTANT  SE 

578  Same  as  71  SE 

5058  995  resident  students  +  ROF  +  4058  Cl  students;  SE 

8  Sep  82  SAR;  CONSTANT 

250  CONSTANT  AE 

-  NOT  INCLUDED  IN  ESTIMATE  AE 

10000  CONSTANT  SE 

16000  1000  students  *  4  courses/student/qtr  *  AE 


PACE  ii 


4  qtrs/yr ;  CONSTANT 

79 

1400 

CONSTANT 

SE 

80 

1125 

225  faculty  members  *  5  TDYs/member/yr ; 
CONSTANT 

AE 

81 

5400 

5121  +  1  yr  estimated  growth  +  ROF 

SE 

82 

50 

CONSTANT 

AE 

83 

NOT  INCLUDED  IN  ESTIMATE 

AE 

84 

NOT  INCLUDED  IN  ESTIMATE 

AE 

85 

NOT  INCLUDED  IN .ESTIMATE 

AE 

86 

NOT  INCLUDED  IN  ' ESTIMATE 

AE 

87 

NOT  INCLUDED  IN  ESTIMATE 

AE 

88 

NOT  INCLUDED  IN  ESTIMATE 

AE 

NOTES 

1.  *  indicates  multiplication,  e.g.  4*5  means  4  times  5.  2.  These  estimates 

are  for  the  database  at  the  end  of  the  first  year  of 
operation. 

COMMENTS  ON  THE  TERMS  USED  IN  THIS  LIST  MAY  BE  FOUND  ON  THE  FOLLOWING  PAGE 
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TERMINOLOCY  EXPLANATION 


STAFF  ESTIMATE  (SE) 

Some  staff  or  faculty  member  from  the  appropriate  department  provided 
either  the  estimate  shown  or  the  major  input  for  arriving  at  it. 


AUTHORS  ESTIMATE  (AE) 

The  authors  estimated  the  figure(s)  based  upon  available  information  or 
experience. 


ACTUAL  COUNT  (AC) 

The  estimate  shown  was  arrived  at  by  counting  the  appropriate  raw  data. 


8  Sep  82  SAR 

The  8  Sep  1982  copy  of  the  Significant  Activities  Report  published  by 
AFIT/DP  for  AFIT/DA. 


CONSTANT 

The  estimate  represents  a  value  which  is  relatively  independent  of  time. 
It  could  be  an  average  or  an  actual  value  which  remains  steady. 


ROUND  OFF  FACTOR  (ROF) 

Any  estimate  which  has  this  factor  wa's  rounded  up  to  a  value  which  was 
easier  to  use  in  calulations.  (e.g.  900,  990  and  995  all  would  be  rounded 
up  to  1000) 
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MISSING  DATA  ELEMENTS  FOR: 


AFIT/LS 


STUDENT  DATA:  Place  of  Birch,  Religion,  Childrens  names,  GRE/GMAT  scores 
(other  than  totals),  projected  assignment,  CPA,  Training  report  data, 
transcript  (explicit) 

FACULTY  DATA:  Dependent  Names,  Religion,  Parking  space  assignment,  PME 
data,  Teaching  hours 

AWARDS:  Criteria  for  selection,  date  award  should  be  submitted 
COURSE  DATA:  Course  Outline 
PROBATION  STATUS:  Name,  Date  Entered 

END  OF  COURSE  CRITIQUES:  Name,  Student  Status  (PCE  or  grad),  Course 
Number  &  Offering,  Date  critique  completed 

END  OF  PROGRAM  CRITIQUES:  Name,  Student  Status,  (PCE  or  grad).  Date  cri¬ 
tique  completed 

SURVEY  OF  GRADUATES:  Student  Name,  Duty  Title/Assignment,  Date  survey 
completed.  Name  of  Supervisor 

SURVEY  OF  SUPERVISOR  OF  GRADUATES:  (Same  as  SURVEY  OF  GRADUATES) 

BUDCET:  School,  department,  EEIC,  FY  allocation,  Quarterly  allocation 
PCE  STUDENT  LOAD:  Requirements,  Quotas,  Fill  Rate 
PART  TIME  STUDENTS:  Students  Program 
SUSPENSE  LIST:  Date,  Project  due 

OTHER  GENERAL  TYPES  OF  DATA  REQUESTED  BY  AFIT/LS : 


Faculty-Staff  positions  which  are  open. 

Ceneral  Registrar  type  data. 

Recall  Roster. 

For  all  military  faculty  members,  all  MPC  data  which  is  not  already 
acounted  for  in  the  design. 

Ail  the  UMD  data  for  the  faculty  and  staff  so  they  can  "MANAGE  THEIR 
VACENCIES" ,  e.g.  Name,  Position  Number,  AFSC,  Remarks 
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SF52  Daca: 


WHEN 

PASSED 

TO: 

ED 

DATE: 

WHEN 

PASSED 

TO: 

DET  10 

DATE: 

WHEN 

PASSED 

TO: 

CLASSIFICATION 

DATE: 

WHEN 

PASSED 

TO: 

HIRING 

DATE: 

WHEN 

PASSED 

TO: 

ACTIVITY  FOR 

DATE: 

HIRINC 


OTHER  IMPORTANT  COMMENTS: 


Colonel  Smith  expressed  the  following  concerns: 

1.  Decide  on  our  database  management  system  fast.  Try  to  get  a  free 
one  so  we  don't  get  hung  up  in  procurement. 

2.  Save  us  some  fields  so  we  can  add  data  elements  later. 

3.  Please  don't  centralize  just  for  the  sake  of  centralization.  If 
we  do,  it  will  bog  down  and  become  useless  because  it  is  too  hard  to 
make  changes.  Keep  it  user  friendly  by  making  it  user  specific. 


(NOTE:  Data  on  items  missing  at  the  LS  division  level  includes  only  that 
data  which  was  not  already  listed  above  for  the  directorate.) 


OFFICE  SYMBOL:  LSY 

Expended  TOY  money  as  part  of  department  budget. 

Validated  Advanced  Academic  Degree  (AAD)  positions  in  USAF  by  major  com¬ 
mand  . 

Validated  Advanced  Academic  Degree  (AAD)  positions  filled  by  compatible 
AAD  holders. 

Assignment  of  numbers  of  AFIT  degree  program  graduates  to  AAD  positions 
and  to  non-AAD  positions. 


OFFICE  SYMBOL:  LSM 

Thesis  abstact. 

Manpower  authorization  data  by  grade,  AFSC,  FYQTR,  position  number. 

Personnel  data  matched  by  position  number,  for  both  military  and  civi¬ 
lian. 

Planning  factors  for  TDY  and  budget  estimation  requirements  (Common  loca¬ 
tions).  Data  required  includes  locations  and  airfares  (both  military  and 
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] 


civilian),  perdiem  (both  military  and  civilian),  and  average  registration 
fees. 

Additional  student  data:  output  assignment,  including  command  and  loca¬ 
tion,  output  AFSC,  and  duration  of  output  assignment.  (Tie  to  MPC 
required) 

Requirements  for  advanced  academic  degrees.  Capability  required  to 
obtain:  a)  number  of  academic  degree  requirements  by  speciality  code  b) 
number  of  graduates  in  the  inventory  possessing  the  degree  code. 


OFFICE  SYMBOL:  LSP 
Contract  regulation  manuals. 


OFFICE  SYMBOL :  LSB 

Data  on  faculty  consulting/ research  interest  or  activities  (including  a 
keyword  search  facility). 

Data  on  faculty  teaching  Interests  and  activities. 

Compendium  of  people  in  AFIT  Speakers  Bureau. 

Data  on  quality  circles,  e.g.,  literature  references,  consultants,  con¬ 
tacts  Current  address  for  any  student  ever  at  AFIT. 

Data  from  a  proposed  learning  style  questionnaire  to  be  given  to  all 
incoming  students. 

Data  from  a  teaching  style  questionnaire  to  be  given  to  all  faculty. 

The  data  and  the  ability  to  isolate  it  for  students  in  teleteach  and  can¬ 
did  classroom  courses. 

Data  on  all  previous  work  experience  of  all  students  and  staff 
(residents) . 

Thesarus  of  keywords  for  the  database  as  a  whole. 

Data  on  student/faculty  hobbles. 

Student  housing  requirements. 

Emergency  phone  pyramid. 
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MISSING  DATA  ELEMENTS  FOR; 
AFIT/EN 


STUDENT  DATA;  Place  of  Birth 

STAFF:  Dependent  names,  Religion,  all  previous  academic  ranks,  profes¬ 
sional  development  data,  honors  (if  not  recorded  in  AWARDS),  professional 
registration,  civil  organizations. 

COURSE  DATA:  Course  Outline 

Ceneral  Registrar  type  data 

Past  faculty  course  assignment  data 

FACULTY  REPLACEMENTS:  Name  of  person  being  replaced 

(NOTE:  Data  listed  as  missing  at  the  division  level  does  not  include  data 
already  listed  at  the  EN  directorate  level) 


OFFICE  SYMBOL:  ENA 

Authorization  figures  for  EN  manpower  report  (Manning  figures  will  be 
available  in  the  database  as  designed,  assuming  that  secretaries  and 
technicians  are  considered  to  be  staff  and  are  distinguishable  from  each 
other,  and  are  both  entered  into  the  STAFF  relation.) 

Maintenance  cost  data. 

Telephone  Control  Report  data. 

For  students  and  staff,  data  on  the  type  of  security  investigation  that 
has  been  completed  on  them,  as  well  as  their  clearance  level  and  the  date 
their  security  clearance  was  completed. 

Data  on  those  students  currently  in  Phd  programs  and  scheduled  for  AFIT 
faculty  positions. 

AF  Form  991  data. 

AP  Form  379  data. 

AF  Form  1098  data. 

SF  971  data. 

Data  for  tracking  status  of  supplies,  equipment,  maintenance,  reimburse¬ 
ments,  and  OA's. 
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OFFICE  SYMBOL:  ENP 


IMPORTANT  COMMENTS: 

ENP  would  agree  to  storing  data  on  their  staff  in  the  database  only  if 
they  had  total  control  over  the  data,  Including  limiting  access  to  the 
data  only  to  ENP. 

OFFICE  SYMBOL:  ENC 

PUB  DATA:  page  numbers 
COURSE  DATA:  Classification 

OFFICE  SYMBOL:  ENS 

Data  for  training  reports. 

AFIT  Form  89  data. 

OFFICE  SYMBOL:  ENY 

STUDENT  DATA:  Religion 
DISSERTATION  DATA 

CRADES:  Indicator  on  grade  data  telling  that  the  given  grade  was  for  a 
repeat  of  the  class. 

COURSE  DATA:  ABET  catagory 

PAST  COURSES:  ABET  Catagory 

FOREIGN  STUDENT  DATA:  TOEFL  score 

Consortium  cross  registration  data 
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HISSING  DATA  ELEMENTS  FOR: 


AFIT/LD 

Ability  to  search  thesis  data  using  subject  keywords. 

PUB  DATA:  Report  Number,  AD  Number,  Volume,  Issue,  Pages. 

BOOKS:  Publisher,  Edition,  Price,  ISBN  number.  Requester. 

Recurring  data  for  serial  updates:  Volume,  Edition,  Date  (month  pub- 
1 lshed) . 

HOLDINGS:  Author,  Title,  Subject,  Copyright  Jate,  Call  Number,  Location 
(Bldg  number),  Volumes  &/or  Editions  (as  required).  Includes  titles  of 
conference  and  symposium  proceedings  and  series  listings. 

Circulation:  Registration  student  name,  card  number,  class,  date 
registered,  date  registration  expires.  For  non-students ,  date  registered 
and  date  registration  expires. 

Data  on  Balance  record  of  library  acquisitions  by:  library,  type  books, 
type  bound  periodicals,  theses. 

Data  on  fund  commitments  by  school  and  for:  books/perlodicals,  deposit 
accounts,  binding,  computer  services. 

AF  971  data  with  training  records  including  name,  date,  and  subject. 
Also,  attendance/ time  data. 


Statistics  on: 

circulation  -  books,  periodicals,  reports 
registration  -  total,  new,  mil,  civ 
interlibrary  loan  -  sent,  received 
photocopies  -  sent,  recieved,  number  of 
pages 

microfiche  -  recieved,  with  number  of  fiche  pages 
reports  received/totals 
reports  requested 
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MISSING  DATA  ELEMENTS  FOR: 
AFIT7DA 

STUDENT  DATA:  Place  of  Birch,  Religion 
FACULTY  DATA:  Dependent  Names,  Religion 
COURSE  DATA:  Course  Outline 
POM  DATA  (5  year  plans) 


MISSINC  DATA  ELEMENTS  FOR: 

afit7pa 

STUDENT  DATA:  Place  of  Birth,  Religion 
STAFF  DATA:  Dependent  Names,  Religion 


MISSINC  DATA  ELEMENTS  FOR: 

afitTed 

Any  teleteach/candid  classroom  data  not  Included  in  present  database 
design  AFIT(CI  &  RR)  lnput/output  by  month,  by  service  and  intra  service 
breakdowns* 
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MISSING  DATA  ELEMENTS  FOR: 

AFIT/ACB 

(NOTE:  Thi6  data  was  recieved  from  ACB  under  Che  cltle  “ADP  REQUIRE¬ 
MENTS’*.  It  is  presented  in  its  entirety  in  order  to  not  distort  it  and 
some  of  it  may  included  in  the  database  design  in  some  form  already.  The 
main  reason  much  of  this  data  was  not  included  was  because  the  form  in 
which  it  was  recieved  did  not  lend  itself  readily  to  being  broken  down 
into  the  individual  data  elements  required  for  the  database.  This  area 
required  an  in-depth  analysis  of  its  •’  own  l.i  order  to  determine  the 
detailed  requirements  and  data  elements  needed  to  fulfill  them.) 


Data  on  the  following  areas: 

TDY  (Student)  LS,  EN,  DE 
1.)  School 

A)  Total  class  and  individual  student  TDY  costs. 

B)  Entry  of  estimates  (EEIC's  407,408,409). 

C)  Entry  of  Actual  Costs  (EEIC's  407,408,409). 

a)  Comparison  of  estimates  vs  actual  (over/under  dollars). 

b)  Percentages  of  estimates  vs  actual. 

D)  Comparison  of  Prior  Fiscal  Years. 

a)  to  dollars  (actual  and  estimates). 

E)  Computation  of  course  and  travel  days. 

a)  Develop  cost  of  per  diem  per  day  -  EEIC  409. 

b)  Develop  Aug  days  (include  travel  days)  of  each  course. 

F)  Project  Fiscal  Year  costs  based  on  program  completions, 
costs  and  balance  of  fiscal  year  remaining. 

TDY  (Student)  Cl 

1)  Program  (AECP,  HPSP,  etc.) 

continue  as  above 

TUITION  Cl  (Costs  and  man-year  computations) 

1.)  PROGRAM  (AECP,  HPSP,  etc.) 

A)  School  and  course. 

B)  Dates  of  entry  and  completion. 

a)  No.  of  days,  months  attended  for  computation  of 
man-years . 

C)  Costs  of  Tuition  (by  student  &  school). 

a)  Period  of  billing  (Term  &/or  year). 

b)  Computation  of  fiscal  year  costs. 

D)  Computation  of  Man  Year  Costs/Entries, 

a)  STUDENT  COSTS  STUDENT  COSTS 

MYs  Entries 

E)  Comparison  of  Prior  Fiscal  Years  (2  years  prior, 
current  +  1  year  forward). 

a)  Total  costs  by  school. 

b)  Cost  per  student. 

c)  Cost  per  man  year. 

F)  Project  fiscal  year  costs,  MYs  by  program  based  on 
completions,  costs,  and  balance  of  fiscal  year  regaining. 

C)  Program  estimates  reimbursable  to  students  for  textbooks. 


Appendix  IJ 


PACE  8 


supplies,  etc. 

a)  identify  payment  totals  and  project  balance  to  be 
paid  based  on  MYs  and  entries  by  program. 

BUDGET  PROGRAM 

1.  Retrieval  of  data  in  2750  ABU/b3500  system. 

2.  Development  of  budget  by  fiscal  year. 

a)  By  PE  code,  EEZC,  and  RC/CCs. 

b)  Compute  estimates  based  on  bogey,  prior  year  requirements 
and  future  year  program  changes. 

c)  develop  distribution  of  funds  based  on  annual/quarterly 
authority  available. 

1)  track  unfunded  requirements. 

3.  Track  AF1T  budget  through  fiscal  year, 
a)  Compare  programs  to  obligations. 

1)  Develope  rates/trends. 

2)  Project  future/EOY  costs  for  current  FY. 
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INTRODUCTION 


This  report  contains  the  final  results  of  the  analysis  of  the  AFIT  information 
and  data  requirements  survey  and  analysis  plus  an  evaluation  of  commercially 
available  Data  Base  Management  Systems  (DBMS).  For  additional  background 
material  or  more  detailed  explanations,  the  reader  is  referred  to  the  complete 
AFIT/EN  thesis  by  Capt.  Ricks  and  Lt.  Colburn  concerning  the  Consolidated  AFIT 
Database  and  Information  System  (CADIS).  This  report  is  an  extract  of  that 
thesis  and  presents  only  the  results  of  the  project.  Subjects  such  as  the  general 
capabilities  and  functions  of  a  DBMS;  the  reasons  behind  a  centralized  database 
and  a  detailed  explanation  of  the  DBMS  evaluation  process  are  covered  in  detail. 
Copies  may  be  obtained  by  contacting  Maj.  Charles  Lillie,  AFIT/EN,  x52024. 


• -  RESULTS  AND  CONCLUSIONS  OF  THE  AFIT  DATA  ANALYSIS 

Cf 

The  process  of  conducting  an  in-depth  requirements  analysis  has  provided  a 
great  deal  of  data  and  knowledge  about  both  the  overall  and  specific  information 
requirements  of  AFIT.  In  order  to  adequately  present  this  enormous  amount  of 
information,  gathered  from  interviewing  approximately  40  people  over  a  four 
month  period,  the  data  has  been  grouped  into  seven  general  categories.  These 
categories  include  the  basic  assumptions  and  ground  rules  which  governed  the 
interviews,  the  actual  results  of  the  interviews,  any  unidentified  or  incomplete 
data  requirements,  recommendations  for  the  management  and  organization  of 
the  Consolidated  AFIT  Database  and  Information  System  (CADIS),  an  implemen¬ 
tation  plan,  and  possible  interfaces  to  CADIS. 

General  Assumptions  of  the  Data  Analysis 

_ _  The  basic  assumption  is  that  the  previous  thesis  by  Lt.  Allred  would  serve  as 

tv  basis  or  starling  point.  l)y  using  his  results  il  would  be  possible  to  gain  a  great 
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deal  of  insight  into  the  nature  of  the  requirements  for  the  remainder  of  AFIT. 
Another  assumption,  and  one  perhaps  just  as  basic,  was  that  a  single  consoli¬ 
dated  and  integrated  database  would  best  serve  the  needs  of  AFIT.  This  does 
however,  include  a  distributed  database,  or  one  whose  data  resides  on  more 
than  one  computer,  but  specifically  excludes  multiple,  independant  database 
systems. 

The  general  guidelines  adopted  in  reqards  to  the  overall  conduct  of  the 

t 

requirements  survey  and  analysis  were  designed  so  as  not  to  impede  or  restrict 
the  type  or  nature  of  the  input.  Primarily,  all  requirements  were  considered  to 
be  valid.  Users  were  not  questioned  as  to  why  a  particular  piece  of  information 
was  needed,  only  how  it  would  be  used.  Therefore,  all  requirements  were  con¬ 
sidered  valid  for  possible  inclusion  the  database  design.  This  ultimately  resulted 
in  an  analysis  which  was  of  a  greater  depth  than  anticipated  and  more  inclusive 
than  any  done  previously. 

The  other  procedural  guideline  which  was  used  also  concerned  the  data 
requirements.  Requirements  which  were  incomplete,  not  clearly  defined  or 
beyond  the  scope  of  the  final  project  would  not  be  included  in  the  database 
design.  However,  in  the  interest  of  completeness  and  accuracy,  all  such  require¬ 
ments  are  listed  seperately,  along  with  who  identified  it  a!nd  an  explanation  as  to 
why  it  was  not  included. 

General  Comments  on  the  Interviews 

The  reception  by  the  vast  majority  of  people  contacted  in  regards  to  this 
project  was  enthusiastic  and  supportive.  However,  most  expressed  frustration 
and  dissatisfaction  over  the  inability  to  maintain  and  effectively  use  the  infot  (na¬ 
tion  required  by  their  organization.  Current  functions  and  responsibilities,  plus 
current  and  projected  requirements  and  problems  were  all  discussed  freely  and 
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openly  in  a  professional  and  receptive  manner. 

Almost  universally,  it  was  expressed  that  CADIS  was  desperately  needed  and 
that  once  implemented,  would  go  a  long  way  toward  alleviating  some  critical 
problems,  assuming  certain  principles  were  kept  in  mind.  Foremost  of  these 
was  that  such  a  system  must  provide  easy  access  to  the  database  plus  the  abil¬ 
ity  to  conveniently  query  and  manipulate  the  data  as  need  be.  Applications  pro¬ 
grams  and  their  subsequent  support  was  generally  not  desired  because  an  ade¬ 
quate  DBMS  could  give  them  greater  flexibility  through  the  query  facility  and 
report  generator  without  the  cost  of  software  development  and  maintenance. 
When  discussing  the  need  for  reports  and  other  required  documents,  it  was 
found,  as  expected,  that  if  proper  facilities  were  present,  the  need  for  many 
paper  records  and  inter  departmental  reports  would  vanish. 

The  School  of  Engineering  (AF1T/EN)  and  the  School  of  Systems  and  Logis¬ 
tics  (AF1T/LS)  were  interviewed  in  greater  depth  than  other  areas  because  some 
of  the  basic  data  elements  used  were  a  result  of  the  previous  in-depth  analysis. 

It  was  felt  that  the  individual  department  heads  should  be  contacted  in  order  to 
revalidate  their  overall  requirements.  In  most  cases  this  resulted  in  a  great  deal 
of  new  information  as  well  as  modifications  to  others. 

Overall  Data  Requirements 

The  overall  goal  of  this  project  was  to  identify  all  the  data  requirements  and 
design  an  integrated  database  which  would  reflect  all  the  current  needs  of  API!. 
In  reality  however,  some  directorates  presented  data  which  they  did  not  ela¬ 
borate  upon  nor  was  there  time  to  define  completely.  .Therefore  what  was  actu¬ 
ally  gathered  was  a  solid  core  of  highly  common  data,  which  if  implemented  in  a 
tiuiely  manner,  should  satisfy  a  very  large  amount  of  A FH"s  information  require¬ 
ments.  This  reasoning  is  based  on  l he  fnet  that  alma>t  .til  of  l he  requirements 
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expressed  revolved  around  a  sub  set  of  the  overall  data.  This  "central  core"  con¬ 
sists  of  general  student,  faculty  and  staff  data  plus  some  single  relations  which 
provide  necessary  and  more  detailed  additional  information. 

Another  goal  of  those  interviews  was  to  gather  a  list  if  all  the  reports  and 
documents  which  were  used  within  AF1T.  However,  this  has  already  been  com¬ 
pleted  by  AF1T/ACD  along  with  data  flow  diagrams  for  the  entire  organization. 
These  may  be  found  in  the  1981  AF1T  ADP  Master  Plan  . 

The  overall  structure  of  the  database  can  be  found  in  the  form  of  a  diagram 
in  attachment  1.  This  chart  represents  each  of  the  relations  identified  to  date 
plus  a  depiction  of  the  most  important  logical  associations  between  them.  A  line 
connecting  two  relations  means  that  there  is  at  least  one  common  attribute 
between  them  and  that  there  is. also  a'.meaningful  logical  connection  between 
the  two.  All  student  and  staff  data  is  accessed  by  the  Social  Security  Account 
Number  (SSAN)  or  the  person  of  interest. 

Many  attributes  in  these  relations  are  stored  as  codes  or  short  names,  but  a 
user  can  obtain  full  titles  of  expanded  information  on  most  of  these  codes  or 
abbreviated  forms.  This  is  accomplished  by  using  a  logical  connecting  code  and 
retrieving  the  full  description,  or  in  some  cases  by  referring  to  the  data  diction¬ 
ary. 

The  chart  in  attachment  1  denotes  no  other  meaning  than  that  described 
above.  The  size  of  a  figure,  nor  the  length,  nor  the  number  of  lines  implies  any 
information. 

More  information  on  the  content  or  the  database  can  be  found  in  attach¬ 
ments  2.  3,  4  and  5.  the  first  four  essentially  comprise  a  highly  detailed  data 
dictionary,  while  the  fifth  documents  the  database  size  estimates. 

Attachment  2  gives  a  functional  description  of  each  of  the  relations  on  the 
chart  along  with  the  length  of  each  tupte  (record).  Attachment  3  is  another  list 
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of  relations  but  this  one  shows  the  attributes  which  comprise  each  relation  and 
the  key  attributes  (elements)  for  each,  denoted  with  an  Attachment  4  pro¬ 
vides  a  detailed  breakdown  of  all  the  attributes  by  listing  the  size  of  each  attri¬ 
bute  its  description,  an  example  of  how  it  is  to  be  used,  a  list  of  the  relations 

which  incorporate  it,  and  a  list  of  any  synonyms  it  might  have.  -Attachment  5 

/ 

gives,  for  each  relation,  the  estimated  total  number  of  records  stored  in 
memory  at  the  end  of.  the  first  years  operation  of  CADIS.  Also  given  are  the  fac¬ 
tors  going  into  each  estimate  and  the  major  source  of  those  factors. 

Database  Size  Estimation 

The  estimated  size  of  the  database  is  approximately  28M  bytes  of  data.  This 
figure  represents  the  total  amount  of  memory  required  for  one  full  year  of 
operation  (several  relations  maintain  four  quarters  worth  of  data).  No  student 
history,  other  than  a  short  educational  history  for  1000  students,  or  registrar 
data  has  been  included  in  the  estimate. 

This  estimated  figure  was  derived  by  taking  the  size  of  each  relation,  as 
determined  by  the  sum  of  the  lengths  of  its  attribute;,  and  multiplying  it  by  the 
estimated  number  of  tuples  for  that  relation.-  Estimates  for  the  lengths  of  each 
relation  were  derived  by  actual  counts,  estimates  from  faculty  or  staff  members 
or  by  author’s  best  estimation.  These  numbers  may  be  found  in  attachment  5. 

For  case  of  computation  it  was  assumed  that  all  data  would  be  stored  in 
character  format  and  that  one  character  would  occupy  one  byte  of  memory. 
This  estimate  does  not  include  the  core  memory  required  for  the  DBMS  itself  to 
function. 

Missing  Information  and  Data  Elements 

The  list  at  attachment  U.  along  with  the  data  dictionary,  encompasses  the 
entirety  of  the  AI'IT  information, 'data  requirement s  identified  during  the  inter- 


views.  Implementation  of  the  database  as  designed  will  alleviate  approximately 
90*95%  of  the  problems  within  AFIT.  The  imissing  data  was  compiled  from  two 
entirely  difTerent  sources,  the  worksheet  used  during  each  interview  and  com¬ 
ments  by  the  interviewee,  and  represents  which  could  not  be  included  into  the 
design  for  the  reasons  listed  below. 

The  reason  this  data  was  not  included  is  because  it  was:  a)  submitted  too 
late  in  the  design  process,  b)  stated  in  a  format  which  was  much  too  general  in 
nature,  or  c)  various  elements  were  very  specific  to  a  single  area  and  not 
desired  by  anyone  else. 

Because  this  was  a  thesis  project,  the  largest  single  influencing  factor  was 
that  of  time.  Each  interviewee  was  contacted  in  sufficient  time  to  respond  with 
their  requirements  and  have  them  included  (some  were  given  much  more  time 
that  were  others).  However,  there  were  those  who  were  unable  to  identify  their 
total  requirements  quickly  enough,  therefore,  only  that  portion  recieved  early 
enough  was  able  to  be  included.  In  general,  the  data  which  falls  into  this 
category  is  not  to  be  considered  "essential"  and  the  current  structure  will  fulfill 
the  vast  majority  of  the  requirements. 

Each  person  interviewed  was  asked  to  be  as  specific  as  possible  as  to  what 
data  was  required  for  their  area.  Everyone  was  asked  to  use  the  worksheet  to 
mark  their  input  and  any  item  which  was  not  SPECIFICALLY  identified  as 
UNDESIRABLE  as  included.  In  spite  of  this,  some  people  simply  identified  their 
"general  ADP/information  requirements"  in  a  very  general  and  non  specific 
manner.  For  instance,  the  most  common  area  identified  like  this  was  "budget 
data".  Because  of  the  nature  of  this  thesis,  there  was  insufficient  time  to  per¬ 
form  the  in-depth  system  analysis  required  to  translate  this  type  of  request  into 
actual  database  requirements.  AFIT  will  have  to  supply  the  qualified  personnel 
to  work  with  these  areas  and  perform  this  lengthy  an.dy.-is  at  a  later  date. 


0CB  Report 


7 


19  Nov  02 


finally. 'most  areas  supplied  data  which  was  rather  narrow  in  use  and  was 
oriented  to  a  small  subset  of  the  directorate  (mainly  the  AF1T/EN  and  LS  direc¬ 
torates).  This  type  of  data  was  excluded  because  it  was  felt  that  because  they 
were  not  really  “common",  and  should  be  reviewed  for  desirability  and  applica¬ 
bility  across  the  directorate  prior  to  their  inclusion. 

RECOMMENDED  CADIS  MANAGEMENT  STRUCTURE 

Volumes  and  volumes  of  material  have  been  published  over  the  years  on  the 
technical  aspects  of  DBMSs.  On  the  other  hand  comparatively  little  has  been 
written  on  the  subject  of  management  techniques,  practices  or  methods  associ¬ 
ated  with  implementing  and  running  such  systems.  According  to  what  literature 
is  available  it  seems  to  fall  upon  the  individual  organization  to  review  their  situa¬ 
tion  and  develop  their  own  methods.  There  is  however,  a  set  of  sound,  concrete 
reasons  for  going  to  the  trouble  of  developing  such  a  structure.  "The  database 
will  have  a  major  impact  on  the  enterprise,  not  only  in  terms  of  ae»>-flts  bu;„  in 
terms  of  problems.  Its  fundamental  aspect  of  the  sharing  of  data  among  users 
and  of  greater  central  control  of  data  are  just  the  type  of  changes  that  can  have 
severe  political  repercussions  within  an  organization."  (REF  2.  p  5-1) 

In  order  for  an  integrated  database  to  be  effective,  such  things  as  the  set¬ 
ting  of  standard  definitions,  formats  and  usages  for  all  data  elements  plus  the 
associated  monitoring  and  enforcement  of  these  standards  are  essential.  This 
will  insure  the  existence  of  accurate  and  consistent  data  for  all  users  who  will 
quickly  come  to  depend  heavily  upon  the  database  for  meeting  their  mission 
requirements. 

"Resentment  to  the  disciplines  imposed  by  the  database  can  often  arise; 
same  departments  might  insist  on  applying  their  own  standards  [or  methods  of 
database  management].  Such  difficulties  can  be  overcome,  but  only  if  the  con¬ 
tinued  and  dedie. rt i'd  support  [and  guidance]  of  senior  management  is  assured." 
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(REF  2.  p  5-1) 


The  solution  most  often  adopted,  and  recommended  by  industry  practice 
and  writing,  is  to  establish  a  specialized  area  of  the  organization  whose  primary 
consideration  is  the  management  and  control  of  the  database  and  its  operation. 
This  'manager*  must  be  "familiar  with  the  use  and  nature  of  all  the  data,  ...be 
vitally  concerned  with  the  performance  of  the  system  and.. .be  able  to  negotiate 
with  and  resolve  conflicts  between  user  departments..."  (REF  2,  p  5-24).  In 
short  this  position  should  be  fliled  with  someone  who  is  totally  competent  in  all 
the  technical  aspects  of  a  DBMS  plus  have  intimate  knowledge  of  the  organiza¬ 
tion  and  its  operation.  But  most  importantly,  he  must  be  someone  who  has  the 
authority  to  make  and  enforce  decisions  involving  the  database. 

AlFIT  Management  Features  Sc  Problems 

In  most  respects  AFIT  is  nr  different  than  other  civilian  and  government 
organizations.  There  is  a  shortage  of  qualified  personnel  and  those  who  are 
available  do  not  have  the  necessary  database  experience  to  implement  and  con¬ 
trol  such  a  project.  For  the  most  part  AFIT  will  cope  with  these  universal  prob¬ 
lems  just  like  everyone  else  and  rely  on  the  available  pool  of  expertise  from 
other  areas  and  accomplish  the  project  anyhow.  There  are  some  problems 
which  while  they  are  not  unique  to  AFIT,  present  some  real  obstacles. 

There  is  a  decided  lack  of  practical  experience  with  the  design,  implemen¬ 
tation  and  management  of  DBMSs.  This,  coupled  with  the  fact  that  this  would  be 
a  "new  start"  project  could  combine  into  a  deadly  combination  if  the  proper  pre¬ 
cautions  are  not  taken  immediately. 

AFIT  has  a  diverse  community  of  users  which  view  the  concepts  of  database 
systems  and  data  automation  from  three  extremely  differing  perspectives;  that 
of  academic,  administration  and  real  world.  The  result  is  a  situation  not  too 
uncommon,  that  is,  differing  opinions  on  the  control  of  data  and  the  methods 
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and  procedures  for  implementing  a  centralized  database. 

CADIS  Management  Recommendations 

The  optimum  solution  for  the  administration  of  CADIS  appears  to  be  one 
With  two  components.  First,  "the  solution  most  frequently  offered  for  this  type 
of  situation  is  placing  the  administrative  responsibilities  in  a  staff  position, 
reporting  directly  to  the  highest  manager  responsible  for  data  processing  in  the 
organization."  (REF  1,  p  6)  Secondly,  "the  database  administrator  functions 
should  be  a  team  rather  than  a  single  manager"  (REF  2,  p  5-24) 

The  Database  Administrator  (DBA)  position  is  a  very  demanding  one.  He  is 
faced  with  deciding  such  things  as  "resolving  conflicts  of  ownership  if  several 
departments  wish  to  amend  or  retrieve  the  same  data.. .negotiating  with  users  to 
establish  who  has  the  right  to  access  or  change  data  items. ..provide  recovery 
facilities  and  establish  precations  for  applications  in  the  event  of  a 
breakdown. ..establish  data  entry,  edit  and  validation  standards,  and  maintain 
the  data  dictionary."  (REF  2,  p  5-26,27)  "For  the  data  administration  to  have 
sufficient  authority  to  be  accepted  by  user  departments,  to  reconcile  their 
conflicting  requirements  for  data,  and  to  be  able  to  enforce  standards,  the  posi¬ 
tion  must  be  relatively  senior  within  the  enterprise."  (REF  2,  p  5-?) 

Based  on  the  above  comments  it  is  recommended  that  AF1T  initiate  two 
seperate  levels  or  areas  of  administration  for  CADIS.  The  first,  that  of  the  Data¬ 
base  Administrator  (DBA),  should  be  a  senior  member  of  the  staff  with  sufficient 
authority  and  knowledge  of  the  organization  to  shepherd  the  database,  witri  all 
of  its  growing  pains  through  to  full  adulthood. 

To  aid  the  D13A,  and  as  part  of  the  first  level  of  CADIS  administration,  each 
directorate  should  have  a  single  representative  or  Data  Administrator  (DA) 
which  would  represent  the  views  and  needs  of  their  respective  functional  ureas. 
Requirements  and  problems  .would  first  be  reviewed  by  a  DA  for  clarity. 
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consistency  and  practicality.  He  should  also  be  able  to  answer  any  question 
about  current  data  usage  and  meaning  as  well  as  act  as  the  focal  point  for  any 
problems  or  changes  to  the  database  originating  from  or  directed  to  his  direc¬ 
torate.  Once  discussed  at  this  level,  anything  of  interest  to  the  community  of 
users,  valid  changes  to  the  structure  of  the  database  or  disputes  should  be 
taken  to  the  DBA  for  review  and  action.  The  DBA  would  check  them  for  validity, 
then  for  consistency  against  prescribed  rules  and  standards  and  act  accord¬ 
ingly. 

Once  the  DBA  has  approved  the  changes  or  resolved  any  problems  with  the 
recommendations,  they  would  then  be  passed  on  to  the  other  component  of 
CADIS  management,  the  Database  Manager  (DBM).  This  person  or  group  would 
act  only  on  the  direction  of  the  DBA  and  should  noC  be  a  member  of  the  staff  but 
someone  with  a  more  technical  orientation  toward  DBMSs.  This  must  be  the 
case  because  he  is  the  one  who.  will  monitor  and  be  in  charge  of  the  DBMS 
software,  make  any  changes  to  the  structure  of  the  database  as  dictated  by  the 
DBA.  as  well  as  being  the  interface  to  the  vendor  and  acting  as  the  ultimate  in- 
house  technical  representative.  The  DBM  should  not  be  involved  in  data  oriented 
problems,  but  only  in  the  efficient  operation  of  the  DBMS  itself  on  whatever  com¬ 
puter  system  it  is  installed. 

It  is  very  likely  that  the  CCB  could  suffice  for  the  first  level  of  the  previously 
mentioned  structure,  with  one  member  appointed  to  be  the  DBA,  and  the  direc¬ 
torate  representatives  ,  or  their  appointees,  acting  as  the  DAs.  The  second  level 
of  administration  could  be  performed  by  AF1T/ACD.  They  could  supply  one  or 
more  people  to  act  as  the  DBM  since  the  type  of  the  technical  expertise  desir  ed 
resides  with  them.  The  job  of  DBM  would  very  likely  be  a  full  time  assignment 
during  the  infancy  of  CADIS  but  could  become  a  background  duly  once  it  is 
operational. 
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In  general;  each  functional  area  needs  to  be  responsible  for  their  own  data, 
AF1T/ACD  should  be  in  charge  of  the  computer  and  the  DBMS  software  and  serve 
as  technical  representative  for  their  combined  use. 

For  this  to  become  a  viable  management  framework,  the  general  level  of 
education  in  regard  to  DBMSs  has  to  first  be  increased.  AFIT  should  immediately 
begin  to  send  people  to  the  database  courses  (basic  and  advanced)  oflered 
within  the  School  of  Engineering.  They  also  need  to  talk  to  vendors  and  visit 
other  AF  installations  which  have  experience  in  database  systems.  Additionally, 
the  heads  of  each  of  the  directorates  should  at  least  attend  the  database  short 
course  available  periodically  at  AFIT/EN.  These  suggestions  are  wholeheartedly 
recommended  because  the  uniqueness  and  nuances  of  DBMSs  dictate  a  need  to 
learn  both  the  theory  and  practices  of  9  database  operation.  Without  this  basic 
understanding  of  the  functions  and  capabilities  of  a  DBMS,  by  all  those  involved, 
it  is  nearly  impossible  to  successfully  implement  CADIS  and  have  it  be  as  useful 
as  it  could  be.  Such  education  should  be  above  and  beyond  the  normal  training 
classes  which  will  be  offered  for  the  DBMS,  usually  by  the  vendor,  once  it  is 
installed.  The  DBA  and  the  DBM  should  be  the  first  to  seek  this  type  of 
knowledge,  and  as  soon  as  possible.  They  would  then  be  followed  closely  by  the 
DAs  and  their  users.  One  can  never  hope  to  build  and  operate  that  which  he 
does  not  understand  and  trust. 

Database  Implementation  He  commendations 

In  order  to  implement  a  database  and  bring  the  users  'on-line'  with  the 
minimum  amount  of  mayhem  and  confusion,  plans  must  be  drawn  up  for  the 
implementation  well  in  advance  of  the  actual  event.  The  purpose  of  this  section 
is  to  suggest  one  scheme  which  would  case  the  'labor  pains'.  A  basic  premise  for 
any  implementation  plan  is  to  try  and  achieve  the  most  results  with  the  least 
expenditure  of  and  resources. 
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First,  a  Database  Implementation  Team  (DBIT).  composed  of  at  least  the 
DDA  and  DBM,  should  evaluate  the  user  community  in  order  to  determine  any 
highly  critical  areas  which  were  not  known  at  the  time  of  the  requirements 
analysis  and  superimpose  them  upon  the  following  general  plan  discussed  below. 
AF1T/ACD  will  have  to  supply  three  people  on  a  full  time  basis  for  about  a  year  in 
order  to  implement  CADIS.  After  this  time,  the  number  could  be  reduced  to  two 
and  eventually  to  one  full  time  and  one  part  time. 


General  CADIS  Implementation 
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The  DBIT  should  not  under  any  circumstances  attempt  to  load  all  the  rela¬ 
tions  prior  to  allowing  the  users  access  to  the  database.  This  is  just  the  common 
sense,  and  good  top-down  implementation  practice  which  will  prevent  massive 
confusion  and  eliminate  wasted  human  and  computer  time  spent  resolving  prob¬ 
lems.  If  all  the  relations  are  loaded  at  once,  this  would  cause  the  majority  of  the 
users,  who  could  operate  with  a  subset  of  the  data,  to  wait  an  unnecessarily  long 
time  before  becoming  operational.  Also,  by  giving  the  data  to  the  users  in 
usable  segments,  they  will  have  the  opportunity  to  fully  evaluate  and  test  the 
features  of  the  system  and  find  any  errors  in  the  data  or  its  structure  easier 
than  if  the  whole  of  their  data  was  present.  When  a  new  system  is  presented, 
"complete”  or  "fully  capable",  the  users  tend  not  to  learn  it  thouroughly  nor 
learn  how  to  use  its  full  capabilities,  but  learn  just  enough  to  get  by. 


The  inclusion  of  the  registrar  should  be  left  aside  at  this  time  because  of 
their  current  automation  effort  and  the  many  complexities  and  controversies 
associated  with  this  type  of  data.  But  if,  at  some  later  date  when  the  all  of  CADIS 
has  been  implemented  and  exercised,  it  is  deemed  desirable,  then  and  only  then 
should  Al'lT/IvKs  inclusion  be  considered.  What  should  be  implemented  at  this 
time  is  the  subset  of  the  registrars  data  which  was  requested  by  the  remainder 
of  Al'IT.  lly  so  doing  it  is  assured  that  CADIS  v. ill  he  ’.roly  useful  to  its  users. 
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Also,  the  mistakes  and  hardships  which  surround  an  organization  trying  to 
operate  with  its  essential  data  needlessly  spread  among  multiple  data  systems 
are  eliminated.  Finally,  it  would  be  easier  all  around,  plus  generate  experience 
with  the  new  system  if  each  user  was  generally  responsible  for  loading  their  own 
data.  No  one  knows  the  data  like  the  individual  departmentmental -users  do,  and 
with  the  DBA  and  DBM  assisting  by  supplying  routines  and  advice,  implementa¬ 
tion  would  proceed  much  faster. 

CADIS  Implementation  Plan 

The  intent  of  this  plan  is  to  install  or  expand  (load  and  verify)  the  database 
in  sections  which  will  do  the  most  good  for  the  most  people.  The  steps  are  not 
necessarily  mutually  exclusive  and  several  steps  may  be  in  various  stages  of 
execution  at  any  given  time.  More  capable  users  may  be  able  to  get  their  data 
loaded  quicker  than  others  and  no  attempt  should  be  r  iaue  to  slow  them  down  if 
they  can  be  administered  adequately. 

The  following  steps  consitute  the  CADIS  Implementation  Plan: 

(1)  The  DBA  and  DAs  should  mutually  establish  the  data  standards  and  codes 
which  will  be  used  throughout  the  system. 

(2)  Define  the  entire  database  structure  in  the  computer  at  one  time.  This 
would  consist  of  those  relations  and  attributes,  along  with  their  rules,  as 
defined  in  the  attachments  or  by  the  DBA.  By  doing  this  first,  modification 
of  the  basic  structure  can  be  kept  at  a  minimum  ai.d  nothing  extra  needs  to 
be  done  when  a  user  is  ready  to  load  a  relation. 

(3)  Initially  load  those  relations  which  comprise  the  'core’  of  CADIS  under  the 
supervision  of  the  DBA.  This  will  allow  AKIT/f'.X,  LS,  DU.  PA,  I'D,  and  Cl  to  go 
into  limited  operation  very  quickly  and  allow  them  to  start  testing  out  the 
structure  ami  their  data.  This  ‘core*  is  comprised  of  the  STUDKNT  mid 
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STAFF  relations  plus  those  relations  which  allow  them  to  function  properly. 
These  core  relations  are:  OFFICES,  ACADEMIC-TITLES;  STUDENTS.  STAFF 
ED-CODES.  SECTION.  FOREIGN_STUDE\T_DATA.  CURRENT-THESES.  CLDATA; 
DE-DATA;  RESIDENT-DATA;  MAJCOMS.  SPOUSES.  LOCATIONS  (only  the  subset 

large  enough  to  allow  minimum  operations),  and  AF1T-CALENDAR. 

/ 

(4)  Once  the  'core'  has  been  installed  and  verified  for  completeness,  the  users 
can  begin  to  load  the  special  purpose  relations  which  pertain  to  their  par¬ 
ticular  operation.  These  relations  include:  BOXES.  LOCKERS.  ED_1I1ST. 
PAST-COURSES.  ED-PLANS,  .  EXTRA-DUTIES,  EXTRA_DUTY_ROSTER. 
DUTY-OFFICER,  PROMOTION-STATS,  QUOTAS.  PCE-DATA,  DEGREE-SOUGHT, 
DEGREES  and  all  the  faculty  related  relations. 

(5)  Complete  the  loading  of  the  LOCATIONS  relation  with  the  remaining  data 
required  by  AF1T/CI  and  others. 

(6)  Finish  installing  the  relations  which  pertain  to  AFIT/CI.  These  relations  are: 
CURRENT-CLPROGRAMS.  CLPROGRAMS.  1NST-PAYMENTS.  INST_POCS. 
SCHOOL/EWLDATA.  MMEP-DATA.  M ED-BO ARD-CE RTIFI CAT1 0 N,  MEDJTOURS 
and  MED-PROG. 

(7)  Load  the  course,  book  and  room  data.  These  relations  consist  of: 
AF1T-C0URSES,  PREREQ,  COURSE-BOOKS,  BOOKS  and  ROOMS. 

(8)  Load  the  course  scheduling  and  other  data  from  the  registrars  system.  This 

includes  the  following  relations:  COURSEJTIMES.  •  STUD-SCHED, 

SHORT-COURSES,  FAC-COURSES,  SHORT-STUDENTS. 

(9)  Load  the  leftover  relations  as  the  data  becomes  available. 

(10)  Begin  loading  the  THESES  and  STUDEN'TJiiST  relations  as  appropriate. 

If  this  type  of  approach  is  followed,  an  effective  i.. an. igcmcnt  structure  is 

« 
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operational  in  about  one  year.  Impacting  on  this  estimate  are  the  decisions  as 
to  the  DDMS  and  the  hardware  and  the  speed  with  which  the  data  is  gathered 
and  prepared  for  entry  into  the  database.  Preparation  could  begin  immediately 
after  the  DBMS  and  hardware  is  decided  upon  by  storing  it  on  the  machine  to  be 
used  via  tapes  or  a  text  editor.  This  data  can  then  be  easily  prepared  for  final 
loading  easier  and  at  a  later  date. 

Interfaces  to  CADIS 

For  purposes  of  this  section,  the  term  "interface"  will  mean  any  data  which 
one  data  system  may  provide  or  recieve  from  another  data  system.  There  is  no 
intention  to  imply  a  method  or  media  for  accompiishin.-,  the  actual  transfer. 

The  following  are  recommended  interfaces  to  CADIS: 


(l)  Let  the  AF  Standard  Personnel  System  periodically  supply  data  on  the  AF 
students  and  staff  at  AF1T.  One  problem  identified  by  AF1T/DP  was  that  the 
data  maintained  by  the  schools  on  their  students  is  almost  always  more 
current  than  that  maintained  by  them  and  the  AF  personnel  system.  By 
having  AF1T/DP  supply  those  attributes  and  allow  them  to  be  updated  via 
the  interface  only,  the  only  way  a  particular  students  record  could  be 
changed  is  by  going  through  AFIT/DP  and  modifying  their  permanent 
record.  Changes  in  the  data  would  then  show  up  in  the  database  at  the  next 
update.  The  primary  reasons  for  utilizing  this  interface  would  be  to  assure 
AFIT  of  the  most  current,  official  data  on  on  a  student.  AFJT  could  therefore 
prevent  their  data  from  becoming  different  from  his  permanent  record  and 
visa  versa.  (NOTE:  AF1T/DE  currently  recieves  a  periodic  data  tape  from 
Randolph  AFB.) 


(2)  Allow  the  registrar  lo  supply  data  to  CADIS  for  the  following  relations: 

couksiljimiis.  Anr_m  ksi:S;  sn.iuscr.i.u  r,uuxn;ivsi:s.  pckjuta. 
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SHORT_COURSES,  SHORT_STUDENTS  and  the  degree  which  a  student  is  seek¬ 
ing.  While  this  data  probably  does  not  exist  in  a  directly  transfcrrable  for¬ 
mat,  enough  can  be  supplied  and  converted  to  guarantee  consistency 
across  AF1T. 

(3)  Let  CADIS  supply  the  registrar  with  the  student  grades  at  the  end  of  each 
term.  Instead  of  faculty  members  filling  out  grade  sheets  and  passing  them 
to  AFIT/RR.  Grades  for  students  would  simply  he  entered  into  CADIS  once 
and  the  whole  school  could  transferred  in  one  easy  step.  Also,  departments 
and  advisors  would  have  the  past  grades  which  they  requested  for  each  of 
their  students. 

(4)  When  the  students'  schedule  is  recieved  from  the  registrar  (via  interface 

« 

number  two)  and  entered  into  CADIS,  a  check  could  be  made  against  the 
students'  educational  plan  (ED_PLANS  relation)  which  would  flag  any  devia¬ 
tion  from  that  plan  for  the  faculty  advisor. 

(5)  When  the  COURSE-TIMES  data  is  supplied  to  CADIS,  that  same  data  could  be 
used  to  update  the  ROOM-SCHED  relation  for  the  current  quarter. 


RESULTS  AND  CONCLUSIONS  OF  THE  DBMS  EVALUATIONS 

General  Procedure 

As  much  information  about  available  DBMSs  was  gathered  from  a  wide 
variety  of  sources  as  was  possible.  The  most  valuable  was  an  article  which 
appeared  in  a  September  1981  issue  of  DATAMATION  which  presented  a  short 
synopsis  of  each  of  DBMS  on  the  market.  With  this  as  a  guide,  further  informa¬ 
tion  was  gathered  as  required  from  other  sources,  such  as  DATAPRO  and  articles 
in  periodicals.  Several  weeks  were  devoted,  in  whole  or  part,  to  studying  this 
data  and  talking  to  several  vendors  in  order  to  gain  a  thourough  Understanding 
of  the  available  DBMSs  and  what  the  current  state-of-the-art  is. 

The  evaluation  was  carried  out  by  searching  for  answers  a  set  of  questions 
and  assigning  points  according  to  pre-defined  rules.  When  there  was  no  data  or 
insufficient  data  so  that  a  firm  determination  could  be  made  concerning  a  item, 
a  value  of  zero  was  assigned.  In  some  cases  the  vendor  was  contacted  for 
clarification  as  well  as  additional  detailed  information  on  those  DENSs  which 
scored  a  70  or  higher  (the  top  14  systems)  on  the  evaluation  was  requested.  The 
total  values  were  calculated  for  each  DBMS  and  they  ranked  accordingly  (attach¬ 
ment  6).  A  chart  showing  how  each  DBMS  scored  in  each  category  may  be  found 
in  attachment  7. 

General  Comments  on  the  Procedure 

Across  the  board  there  is  little  specific,  detailed  information  available  to 
the  public  on  DBMSs.  There  are  several  sources  from  which  very  general  infor¬ 
mation  rnay  be  obtained,  but  little  of  the  type  required  by  this  evaluation. 
DATAI'KO  has  a  fairly  detailed  breakdown  on  DBMSs  (including  most  of  what  was 
need  for  those  systems  listedcd).  but  mainly  on  those  systems  oriented  toward 
HIM  and  other  larger  computer  systems.  It  appears  that  a  large  segment  of  the 
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market  has  been  overlooked  and  DATAPRO's  descriptions  exclude  many  "recent" 
and  very  capable  systems.  Sometimes  that  information  which  was  available  was 
ambiguous  or  misleading  as  to  the  actual  capabilities  and  functions  of  the  DBMS. 

Another  aspect  which  was  difficult  to  pin  down  were  the  DBMSs  which  were 
available  from  within  the  Federal  Government.-'  The  General  Services  Administra¬ 
tion  (GSA)  Federal  Software  Exchange  program  either  did. not  contain  the 
desired  information  or  simply  did  not  list  possible  systems.  One  DBMS  (RIM) 
which  was  written  under  a  government  contract,  known  by  the  author  and  others 
at  AFIT,  was  evaluated  but  did  not  appear  on  the  list.  This  most  likely  is  a  failure 
on  the  part  of  the  organizations  to  list  their  systems  and  not  on  the  system 
itself. 

In  spite  of  the  lack  of  data  in  some  areas  and  because  of  the  way  in  v.  hicb 
the  evaluation  was  structured  it  is  felt  that  those  systems  which  scored  the 
higher  points  are  the  most  suitable  for  AFIT.  It  is  felt,  very  strongly,  that  the 
evaluation  was  sufficiently  encompassing  and  well  rounded  to  adequately  reflect 
the  needs  of  AFIT.  Additionally,  as  was  hoped,  the  best  possible  DBMSs  were 
identified  through  a  fair  and  impartial  process. 

Conclusions 

Several  important  conclusions  were  reached  during  the  course  of  this 
evaluation.  They  fall  into  two  general  categories.  One  deals  with  AFIT  itself  and 
the  other  concerns  the  DBMS  market. 

Most  important  is  the  fact  that  the  capabilities  which  AFIT  requires  of  a 
DBMS  are  well  within  the  current  statc-of-Lhc-art  in  DI"'S  technology.  The  sys¬ 
tems  now  being  marketed  are  extremely  sophisticated  and  written  mainly  for 
the  non-programmer.  They  provide  a  great  deal  of  flexibility  for  the  user  and 
the  organization  alike  in  both  the  manipulation  oT  the  data  and  the  database 
structure  itself.  Additionally,  'they  virtually  all  but  eliminate  the  need  for 
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applications  programs  in  organizations  which  have  information  requirements 
similar  to  AFIT.  Extremely  sophisticated,  english  like  query  facilities  combined 
with  good  security  measures,  report  generators  and  accounting  capabilities  pro¬ 
vide  a  DBMS  which  can  be  virtually  tailored  to  the  individual  users. 

Two  less  significant  facts  were  also  discovered.  As  far  as  industry  views 
databases  and  their  uses,  AFIT  represents  a  rather  small  application.  This  is  in 
spite  of  the  potentially'large  amount  of  data  to  be  housed  in  the  database.  Data¬ 
base  applications  are  generally  classified  by  .the  amount  and  frequency  of 
queries  levied  against  the  data.  Even  at  peak  usage,  AFIT  will  not  amount  to  a 
significant  level,  as  defined  by  community.  Another  thing  learned  was  that  AFIT 
has  a  rather  unusual  mixture  of  computer  hardware  on  which  to  implement  a 
DBMS.  There  are  a  limited  number  of  DBMSs  currently  available  which  can  run 
under  the  UNIX  operating  systems.  However,  those  which  are  available  are  very 
powerful  and  popular.  As  few  as- these  were,  the  number  of  DBMSs  capable  of 
running  on  the  HARRIS  minicomputer  are  fewer  still.  This  situation  severely  lim¬ 
its  the  range  of  possible  DBMS  candidates  for  AFIT. 

Because  of  the  large  number  of  DBMSs  which  were  evaluated,  some  general 
observations  may  be  made  about  the  market  as  a  whole.  Primarily,  there  are 
many  good  DBMSs  which  will  more  than  satisfy  AFIT’s  requirements,  and  at  rea¬ 
sonable  price. 

Secondly,  the  majority  of  the  DBMS  market  appears  to  be  oriented  toward 
IBM  and  DEC  hardware.  This  is  not  all  to  surprising  because  these  two  vendors 
manufacture  the  majority  of  hardware  presently  in  use  throughout  the  world. 
On  the  other  hand,  there  docs  seem  to  be  a  trend  by  smaller  software  com¬ 
panies  to  fill  the  gap  and  provide  capable  and  reliable  DBMSs  for  a  larger  variety 
of  hardware  and  operating  systems.  It  is  probably  safe  to  state  that_  there  is  at 
least  one  DBMS  which  "ill  operate  on  nlrnosl  every  computer  currently  commer¬ 
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dally  available.  This  does  not  necessarily  include  microcomputer  even  though 
they  too  are  being  quickly  accounted  for. 

Recommendations 


Recommendations  for  the  DBMS  to  be  utilized  within  AF1T  to  support  CADIS 
are  based  upon  the  current  hardware  configurations  at  AFIT,  the  information 
requirements  and  performance  characteristics  expressed  in  the  interviews,  and 
the  current  state  of  DBMS  technology. 

It  was  determined  at  the  conclusion  of  the  evaluation  procedure  that  those 
systems  which  scored  a  70  or  higher  were  to  be  considered  as  prime  candidates 
for  implementation.  These  systems  are  the  top  14  systems  out  of  44  evaluated. 
Cost  figures  are  not  included  in  the  recommendations  nor  were  they  considered 
heavily  because  a  specific  price  must  be  negotiated  with  the  vendor  and  might 
very  well  be  lower  or  higher  than  that  quoted  in  the  literature,  depending  on  the 
individual  vendor. 

There  are  two  almost  equally,  highly  qualified  DBMSs  which  should  be  used 
to  implement  CADIS,  they  are  ORACLE  and  SEED.  The  capabilities  and  functions 
of  each  are  almost  identical  in  all  respects.  Each  has  an  advanced  level  of  data 
security,  a  data  dictionary,  fully  capable  report  generators,  database  and  data 
maintenance  facilities  and  a  highly  sophisticated  and  useful  CRT  screen  format¬ 
ting  facility  for  applications  development. 

Two  of  the  most  significant  features  of  these  DBMSs  are  the  security  and 
CRT  screen  formatter.  Security  is  controlled  not  only  with  passwords  and 
person-ids  to  the  attribute  (data  element)  level,  but  they  allow  for  the  logical 
data  views  to  specify  restrictions  on  a  subset  of  data  within  a  relation,  such  as 
STUDENTS.  This  means  that  each  directorate  can  control  the  priveledges  on 
their  students,  or  other  data,  not  only  for  themselves  but  for  the  rest  of  AFIT  as 
well.  As  far  os  can  be  detcmihu  d,  these  arc  the  only  DBMSs  currently  available 
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which  ofler  such  extensive  and  flexible  security  measures  (others  merely  allow 
password  and/or  person-id  protection). 

Almost  as  significant  as  the  strong  security  is  the  existence  of  an  easy  to 
use  (user  oriented)  and  very  capable  CRT  screen  formatter.  This  feature  could 
all  but  eliminate  the  need  for  applications  programs  at  AFIT,  including  those 
required  for  AF1T/C1.  With  the  use  of  any  CRT  which  allows  for  direct  cursor 
addressing,  a  user  may  designate  protected  and  unprotected  areas  for  data 
entry,  specify  fields  which  cannot  be  left  empty  or  blank,  specify  special  edit 
checks  on  the  data  (this  includes  having  the  DBMS  check  the  database  to  see  if  a 
value  is  already  present  in  the  database;  especially  useful  for  codes).  In  addi¬ 
tion,  the  prompts  and  error  messages  the  user  sees  can  be  specified  as  well  as 
special  on-line  ,  application  dependent,  help  files.  The  following  alternatives  are 
strongly  recommended  for  the  implementation  of  CADIS. 

(1)  Acquire  the  ORACLE  DBMS,  currently  on  the  GSA  price  schedule,  and  imple¬ 
ment  it  on  the  PDP  11/34,  PDP  11/60  or  VAX  11/760  under  the  UNIX  operat¬ 
ing  system  (NOTE:  ORACLE  may  be  selected  fer  operation  on  the  HARRIS  at 
a  later  date.) 

(2)  Acquire  the  SEED  DBMS,  currently  on  the  GSA  price  schedule,  and  either 
remove  UNIX  from  one  of  the  PDPs  and  reinstall  the  original  DEC  (VMS) 
operating  system  (SEED  does  not  yet  run  under  UNIX),  acquire  another  DEC 
computer  system  or  some  other  which  will  run  SEED,  or  negotiate  with  the 
vendor  to  make  SEED  operate  on  the  HARRIS  (supposedly  projected  for 
accomplishment  by  the  vendor  in  the  future). 

Both  ORACLE  and  SEED  scored  very  high  in  our  evaluation  (attachment  7) 
and,  after  reeieving  more  detailed  literature  from  the  vendors,  it  seems  that 
they  are  truly  effective,  easy'  to  use  and  rather  popular  and  arc  in  wide  use 
throughout  the  data  processing  am!' business  community.  ORACLE  has  received 
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high  marks  from  the  Strategic  Air  Command  and  is  strongly  being  considered  by 
the  Naval  Post  Graduate  School.  SEED  was  chosen  for  and  is  highly  recom¬ 
mended  by  a  consortium  of  Canadian  universities  and  the  US  NAVY  Weapons 
Development  Center.  Both  vendors  offer  training  and  assistance  in  establishing 
a  database  and  are  available  at  almost  any  hour  to  answer  questions  (SEED 
maintains  a  24  hr  hotline)  or  solve  problems.  It  is  highly.recommended  that  the 
DBMS  which  will  support  CADIS  be  one  of  these  two  systems. 

Another  benefit  for  AFJT  may  be  the  fact  that  both  vendors  alluded  to  a  sub¬ 
stantial  cost  reduction  if  their  system  could  also  be  made  available  for 
“academic"  uses.  By  allowing  students  and  faculty  to  access  the  DBMS  and  use  it 
for  their  own  learning  purposes,  AFIT  might  qualify  for  a  special  “university"  pur¬ 
chase  price. 
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database  management  systems  evaluation  sheet 


DBMS  VALUE 


HIGH  PRIORITY  CONSIDERATIONS 
Rating  Scale:  (Max  “10) 

1.  Current  Availability 

2.  Structure 

3.  AFIT  Computer  Systems  Compatability 

4 .  Memo  ry 

5.  Cost 

6.  Machine  Independence 

7.  Data  Dictionary 

IMPORTANT  OPERATIONAL  FEATURES/CONSIDERATIONS 
Rating  Scale:  (Max-8) 

8.  Applications  Languages 

9.  Privacy  &  Security 

10.  Backup  &  Recovery 

11.  Structure  Definition 

12.  Modifiability  of  the  Structure 

13.  Maintenance 

14.  User  Friendly 

15.  Resources  (optional/required) 

16.  Update/Retrieval  Protocol 

17.  Report  Generator 

18.  Vendor  Support 

19.  Documentation 
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DESIRABLE  FEATURES 

Rating  Scale:  (Max*6) 

20.  Batch/On-llne  Operation 

21.  Util ities/Functions 

22.  Accounting  Package 

23.  Field  Value  Enforcement 

24.  Key  Enforcement 

25.  Secondary  Indexing 

26.  User  Usage  Statistics 


Appendix  1 1 A 


PACE  11 


0*~ 


LIST  OF  DBMSs  ACCORDING  TO  THF.1R  EVALUATED  SCORE 
MAXIMUM  SCORE  WAS  192  POINTS 


DBMS 

VENDOR 

V  CORE 

SEED 

INTERNATIONAL  DB  SYSTEMS 

177 

ORACLE 

RELATIONAL  SOFTWARE  INC 

169 

1DMS 

CULINANE 

154 

RLM 

BOF.INC  COMPUTER  CO 

103 

TOTAL 

CINCOM 

101 

INFO 

HENCO  Inc. 

97 

1NCRES 

RELATIONAL  TECHNOLOGY 

91 

DRS/XSB 

ARAP  ADVANCED  DATA  MCMT  DIV 

32 

SQL/DS 

IBM 

90 

MODEL  204  DBMS 

COMPUTER  CORP  OF  AMERICA 

30 

SYSTEM  38 

IBM 

7  8 

ADABAS 

SOFTWARE  AG  OF  NORTH  AMERICA 

78 

SYSTEM/2000,  2000/80 

INTEL  COKP 

73 

DATACOM/DB 

APPLIED  DATA  RESEARCH 

70 

DPL 

NATIONAL  INFO  SYSTEMS 

63 

INQUIRE 

INFODATA  SYSTEMS  INC 

6  3 

SYSTEM  1022 

SOFTWARE  HOUSE 

60 

DHMS-10/20,  DBMS-11 

DEC 

59 

RAMIS  ll 

MATHEMATICS  PRODUCTS  CROUP 

59 

RAPPORT 

LOGICA  INC 

57 

1MAGF./3000 

HEWLETT-PACKARD 

57 

DMS-90,  DM S- 11 00 

SPERRY-UNIVAC 

53 

DMS-170 

CONTROL  DATA 

51 
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DM-IV 

HONEYWELL 

44 

:o 

IMS,  IMS/VS 

IBM 

44 

UNIBASE 

RLC  CORP 

43 

CREATE/3000 

CRI  INC 

36 

a 

DL1/1 ,  DOS/VS 

IBM 

35 

MADMAN 

CEKERAL  ELECTRIC  CORP 

32 

DBMS  PRIME 

PRIME  COMPUTER  INC 

32 

« 

DBMS-990 

TEXAS  INSTRUMENTS 

31 

CREATE 

COMPLETE  COMPUTER  SYSTEMS 

30 

IDS  I/II 

HONEYWELL 

27 

•* 

►  v' 

SIBAS 

SUIPPINC  RESEARCH  SERVICE 

23 

SIR 

SCIENTIFIC  INFO  RETRIEVAL  INC 

22 

■  ‘  t 

IDOL 

SCIENCE  MANAGEMENT  CORP 

20 

a  o* 

DAI 

CONSOLIDATED  BUSINESS  SYST 

19 

DC/DMS 

DATA  CENERAL 

19 

SUPKRSETUP 

THE  AUTOMATED  QUILL 

18 

* 

AMBASE 

AMCOR  COMPUTER  CORP 

16 

SYSTEM  C 

SOFTWARE  CLEARINC  HOUSE 

16 

- 

DIRECT 

BANCHOHIO  CORP 

15 

• 

MINDS 

MINI  DATA  SYSTEMS 

15 

DATABASE  MANACER  I 

CONDOR  COMPUTER  CORP 

12 

» 
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KOTES:  I.  2  300  me.  2.  50k-*-  3.  30k.  3k  ailntentflca  A.  120k  3.  170k  6.  12-44k  7.  300  ••*.103  •• 

H .  7.3k  4.  17-34*  T  ■  nnt  i»*«I1.iIi!p 


DATA  At.  A  L  VS  I  S  u  u  I.  :>  I  I  o  .  N  A  1  il  i.  I'Us 
ACTUM  AT  ION  up  Till'.  I  h'  1-0  Ml  AT  i  u TTui'  I!  i'.MK  .  i 


.  1'  I  . 


Ill  i-  pur  |io  se  iif  this  ij  u  e  s  i  iuniuilrc  is  in  ■  a  t  h  e  i  i  .  1  1  u  '  .  1 

1  Inn  iiort.ilnlni;  to  t  lie  o  s  t  a  It  I  i  s  li  .1  e  1  1  ■  1  t  !.<■  A  !■'  1  I  /  ('  l  ;  •>  i  ;  i  o 

11I  C  A I  >  I  i>  anil  the  rli‘Velo|n.nit  o  I  1  i  ■  e  .|  u  i  r  ml  .ippl  ii'.il  lull 

p  r  or,  r  a s  .  ilo  spunscs  t  o  t  lie  se  1;  u  e  s  t  1  o  .1  s  s  h  o  t,  l  ii  l>  o  1  o  r ; ,  u  I  1 1  r 

i  11  Siicll  .1  U.IV  as  to  p  r  i)  V  id  «■  s  11  I  I  i  a  1  .  1  l  .1  .1  t  1  l  .)  ,1  i  >1  ill  til 

il  lupfliMi  t  o  I  your  s  v  s  t  o  1  .  I'  1 1  «*  accuracy  a  11 .1  ru..;|i  I  u  lunc  1, 

ill  hot  1 1  the  'il.i  talu  se  ,1 11  il  Lin-  p  r  o  .• r  .1  ■  1  s  w  h  i  c  h  a  ;•  a  e  s  s  it  1.  1  I 
In.-  J  I  r  e  r  I  1  v  lull  uenced  h  ”  your  responses. 


(  1  )  T  h  e  s  or  t  ion  d  e  a  1  s  w  i  t  I,  vu  u  r  current  ■;  i  1  u  1  t  i  o  n  1  s  wo  1 

as  with  o  r  !•  a  11 1  z  a  t  I  0  n  a  !  and  i  11  n  1  i  . .  n  1  i  !  1  1  1  vo  u  1  o  w  u  j  k 


What  is  t  I10  o  r  p.  a  n  i  2.1  t  i  o  a  a  1  t  t  u  ••  t  u  1  <•  i'  I  i 

where  loos  it  fit  within  A  K  1  'i  !  1;  r  I  «■  I  I  y  r 

f  1111  c  t  ion  o  f  each  level  . 

U  it  :i  t  pru|-r,ns  are  managed  hy  Af'l'/Cl  .1  1  whir 
ti  until  area  is  responsible  for  each'.' 

How  ii  o  each  of  the  pro  •  rams  ..1  a  .1  a  ;  e  c!  h  y  f  !  1  /  C.  1  1 

late  to  o  lie  a  no  t  he  r  ? 

I.1  Il  a  L  1  tens  of  il  a  t  a  hoes  each  I  11 11  c  t  i  o  11  1  1  1  1  e  a  re., 

perlorn  its  j  O  h  ?  (  hre.il  t  he  I  .In.."]  I.  V  I  T  /  (’  l  pi'. 


for  each  .lata  o  1  e  1  e  a  t  , 

n  a  .  o  ,  size  a  •  1 . 1  valid  v  a  I  11 1 


Is  t  In 


tiipei/.  1  ’  I  ■  I 


hist  ill  t  lie  known  relationships  between  I  hi 
r.i  e  n  t  s  ■ 


(21  This  section  lea  I  s  with  how  1  lie  lot.,  t  1  <  . .  «•  u  I  s  1  i 

above  are  used.  The  questions  ■  I  e ■  i  1  1 1  I  1  1  a 

u  s  .1  e  a  lid  inner.il  inlonn.it  ion  1  <  ...  1  1  1  >  .  1  u  l  s  .... 


J  li  e  t  wo  h  i'u  .1  I  i‘  a  I  e  'uric:,  o  I 

'■  1  11.HI1'  I  .1  I  .  I  ill  I’e  I  Snail  1 1  a  t  .1  . 

this  I  i  V  1  s  1  0  11  ,  also  ;  i  sc  II  .  s 

which,  relate  to  each. 


1  1  r  1  T  .•  1  I  .•  1  1 

I  U  1 1  1 '  I  i  .  .  . .  . .  all 


1  .  'in  a  routine  basis,  wl  at  i  u  1  o  r .  I  I  t  1 


f  r  o  ii  L'ddi  <>  t  tlit-  c  .i  t  u  r  i  .• iiii  t  1  in,.*,! 

r  i'  q  a  1  r  e  I  ?  (what  <[  ut-  s  t  i  o  n  s  ‘./ill  a  <■  e d  to 

t  i  iw  1  y  answered;  what  rc|Hiit  ,  an!  .1  i  s  ,»  1 

t  i  in- 1  y  >•  e  n  e  r  a  t  >•  ii  ?  ) 

■-  •  hist  >t  n  y  po  s  s  1 1)  1  o  a .!  -•  h  o  c  o  r  n  msu.i  1  ;  i 

V  u  ii  have  e  ut:  on  n  to  re  I  in  tin-  [m.sI  ./ i  e  u  v  l  i  < 
h  e  a  s  k  e  d  * 

For  each  of  t  tie  c.ili-,;or  in,  .!  i  s  t:  u  s  e  !  in  .!  .  A  : 

1  .  1,1  st  t  ii  e  ,t  a  I  a  e  1  one  a  L  s  which  .till  in¬ 

to  fulfill  midi  of  t  tie  queries  v  a  u  list  i- 1!  . 

2.  l.'h  it  is  the  format'  in  which  you  it  -lit 

have  the  answers  to  each  ,|-.n-rv  appear? 

J  .  i'll  at  is  the  format  of  each  o  I  I  lie  r  e  Co  r 


Privacy  mid  Security  requirements  lor  bAhl.:. 


Will)  is  now  authorized  access  to  the  .!  it.  a  a  u  i  wao  oil 
he  authorized  use  of  the  various  relations  t  a 
(  hreuV  down  by  AKIT/lM  pro/riin) 


‘."a  it  r  i'  (.  l  r  i  c  thms  /  a  u  t  ho  r  i  za  l  ion  will  n  e  e  ;!  to 
i  :H  nosed  to  control  access  to  t  he  da  t  a  base  tor  ,  i  a  i  1  s 
use,  dissemination,  review,  el  c.  ? 


Whit  types  of  audit  trails  o i  chance  controls  a r , 
currently  in  effect?  What  will  have  to  he  i  i|i!e  i.-utc, 
within  b  All  1  a  ? 


How  detailed  ;:i  u  s  l  I  he  a  a  o  ■  I  i  t  /  e  h  .  ,- 1,  or  oc  ed  ii  r  e  S  he  (In- 
person,  t  i  la  e  ,  I  till  c  t  l  n  i:  ■  I  a  i'  e  a  ,  i-ti-.l  1 


I  his  sec  I  i  o  n  I  e  a  l  s  .it,  t  a  •  ,,  c  ,  ■  r  ,  i 

t  ii  n  c  t  1  o  u  ■.  o  f  C  Ahls. 


a  i-a  0  I  I  I  t  l  e  .  ,  a 


•  h  *t  is  I  he  si  ill  and  i  • ,  i  u a  t  i  o  a  ,  1 
lie  1  w  Ii  o  Will  he  a  .  I  u  -■  b  A  i.  I  S  > 


Will  t  ll  e  sale  pe  o  ;i  I  ,•  pe  r  t  o  r .  I  I  |  I  l  ,  .  1  hi  - 

a  a  I  >1  ,le  r  v  I  uil.'t  i . .’  1  I  not.  .« i  ..it:  to 


I 


0 


llovi  often  will  the  system  he 


used  lor: 


% 


c 


1  .  Da  t  a  i  11  j>  n  t  ? 

2  .  Data  c  li  a  ti .»  c  s  '! 
1 .  Oucries? 


i 


!)  . 


'..'lut  new  functions  will  have  to  hi-  incorporate-!  i<tn 
'?  AD  i  S  .i  nil  the  application  p  r  o  .■  r  a  i.  a  7  (  o  v  r  r  act  a  i  ■  o  v  e 

present  e  .i  p  a  b  i  1  i  t  i  e  s  ?  ) 


Who  will  act  as  t  tic  functional  u  a  a  a  per  of  the  /!■'!!' /'.I 
portion  of  CADIS?  The  p  r  o  r  a;ii  s  ’?  The  -lata? 
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h  o 
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What  Wo  11  1  '1  be  a 
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to 

restore  : 
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C  .  Are  t  li  e  r  e  any  t  i  r.i  e  pc  r  i  o  !  s  which  i  1  1  r  <■  |  u  i  r  e  a  i  ,  h  l  -• 
t  leant  increase  in  the  use  of  the  system"? 

o.  What  i;  1  nl  ami  decree  of  archive  lata  will  have  to  In- 

retained'?  I’ or  how  Ion-?  Sow  w  i  1  1  it  he  use  1? 

I  .  What  r  a  He.  e  of  turnaround  line  is  i!i  Ih'.l  Ini'  tontine 

i|ueries?  Ad-Uoc  queries'?  Deports? 


I.  Wli.it  ore  the  hncknu  and  fciov.-rv  requi  ts-.s'ip  •,  -  -  i 

desires  for  svs  tom  r  e  1  i  a h  i  1  i  t  v  a  u  !  l  n  t  e  .  r  i  t  v  '? 


A  p  ;>e  a  ■  t  i  \  1  1  I  A 


i’  1 1. . 


I  i  i 


A  FUNCTIONAL  DESCRIPTION  OF  TILE 


AF1T/CIR/M  PERSONNEL  SUBSYSTEM  SOFTWARE  (PSS) 


The  following  is  a  description  of  the  AFIT/CIR/M  Personnel  Subsystem 
Software  (PSS)  from  the  user's  viewpoint.  PSS  is  designed  to  be  an 
extremely  user  friendly  interface  between  CADIS  and  AFIT/CIR/n.  Since 
PSS  is  menu  driven,  the  description  will  focus  on  the  varii  us  menus 
(screens)  that  the  user  will  see  when  utilizing  the  system.  For  any  menu 
which  requests  the  user  to  choose  a  function,  the  user  has  only  to  type 
the  letter  of  the  function  he  wishes  to  perform.  Upon  doing  tils,  PSS 
will  provide  the  appropriate  responses.  Error  messages  for  sui  h  things 
as  invalid  data  or  entering  a  letter  which  is  not  one  of  the  menu  func¬ 
tions  shown  are  printed  in  an  area  at  the  bottom  of  the  screen  reserved 
for  error  messages.  The  cursor  then  returns  to  the  place  on  thi  screen 
where  the  error  was  made  and  the  user  is  given  a  chance  to  try  again. 
PSS  will  continue  to  do  this  until  a  valid  response  is  entered. 

At  any  level  of  PSS,  a  quit  command  (entered  by  typing  a  *'Q"  as  the 
response  to  any  menu)  will  allow  the  user  to  stop  the  current  i  peration 
and  return  to  the  previous  menu.  Users  must  back  their  way  out  of  the 
system  one  menu  at  a  time.  They  also  have  the  opportunity  to  back  up  to 
any  previous  menu  and  then  do  something  different  from  what  they  origi¬ 
nally  did. 

Whenever  a  PSS  function  involving  an  individual  student  is  invoked, 
the  CRT  screen  is  always  divided  into  two  areas  (in  addition  to  the 
"error  footer”  at  the  bottom  of  the  screen),  an  upper  area  called  the 
STUDENT  HEADER  and  a  center  area  for  whatever  screen  display  is  ..ppropri- 
ate  to  the  function  that  was  invoked. 


The  format  for  the  STUDENT  HEADER  is: 


RANK  LAST  NAME,  FIRST  NAME  MI.  FULL  SSAN 

SCHOOL  PROGRAM  OUTSTANDING  SUSPENSE  FLAl 


EXAMPLE : 


2Lt  Dimwitter,  Jonathan  l.  999-55-1234 

Podunk  University  POCDY  * 


NOTE:  1.  The  suspense  flag  will  be  flashing  if  there  an  any  outs.ading 
suspenses  for  the  student,  otherwise  it  is  blaiK. 

2.  T‘*ise  headers  are  displayed  as  write  protected  i  ields  an 
cannot  be  directly  changed  by  the  user. 
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properly  entered,  by  using  the  appropriate  password.  Next,  the  Cl 
Authorization/Access  Check,  program  (CIAAC)  must  be  Invoked.  O.  ce  CIAAC 
has  displayed  SCREEN  0,  a  CADIS  password  and  a  Cl  user  ID  .nust  be 
entered.  This  is  done  by  entering  the  correct  information  in  he  right 
fields  of  SCREEN  0. 


The  format  for  SCREEN  0  is: 


ENTER  PASSWORD  [  )  AND 

Cl  USER  ID  [  1 


The  CADIS  password  will  be  used  by  PSS  latter  to  access  ADIS  as 
necessary.  The  Cl  user  ID  is  used  to  do  two  things.  The  fi  si  Is  to 
logically  partition  the  Cl  data  in  CADIS  into  two  parts,  that  which  a 
given  PM  is  responsible  for  (and  can  directly  access),  and  that  u'nich  he 
is  not  responsible  for  (and  cannot  directly  access),  i.e.  se.ect  the 
proper  users  view.  This  first  part  is  done  by  the  DBMS.  Note:  The  for¬ 
mat  of  the  Cl  user  ID  is  a  four  character  combination  which  beg  ns  with 
Cl  and  ends  with  a  two  letter  code  uniquely  identifying  a  give  .  program 
manager,  e.g.  CIRA. 

The  second  thing  the  Cl  user  ID  does  is  to  allow  PSS  to  .utomati- 
cally  direct  the  user  to  the  appropriate  set  of  user  functions  (i.e. 
CIR/M  or  CIV  functions).  These  two  tasks  would  be  the  responsib  lity  of 
a  module  called  "Authorization/ Access  Checking”.  This  modui.  has  not 
been  defined  in  greater  detail  at  this  time,  since  it  will  be  heavily 
dependent  upon  the  security  capabilities  and  details  of  whichever  DBMS  is 
chosen  to  be  the  basis  of  CADIS. 

Assuming  the  user  entered  an  authorized  Cl  users  ID  and  «  correct 
CADIS  password,  the  next  thing  he  will  see  is  SCREEN  1,  the  dS  entry 
sc  reen . 


The  format  for  SCREEN  1  is: 


SSAN:  (  ]  PH:  (  ) 

SUSPENSE:  [  ]  TYPE:  [  1 

DATE:  (  1 

CREATE:  [  ] 

QUIT:  (  ] 


When  SCREEN  1  is  output  to  the  CRT,  the  last  two  characters  of  the 
Cl  users  ID  entered  in  SCREEN  0  and  today's  date  are  display'd  in  the 
appropriate  fields,  and  all  other  fields  are  blank.  At  this  g’int  the 
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user  has  Che  option  of  changing  the  program  managers  code  (to  last  2 
characters  of  the  Cl  users  ID),  of  viewing  ill  suspenses,  create,'  a  stu¬ 
dent  header  (input  minimal  data  to  enter  a  new  Cl  student  in  CAD.j),  pro¬ 
cessing  an  individual  student  who  is  already  in  the  system,  or  quitting 
(i.e.  return  to  SCREEN  0). 

NOTE:  Assuming  the  user  needs  to  do  anything  involving  anoth  r  PM’s 
area  of  responsibility  (view),  then  he  must  enter  the  ust  two 
characters  of  the  other  PM's  Cl  us'.'f3  ID  into  the  PM  f  old. 
Changing  the  PM  field  is  allowed  to  permit  an  authorli  d  program 
manager  to  examine/change  student  files  of  another  PM  who  is  not 
able  to  perform  these  tasks  for  some  reason,  e.g.,  the  other  PM 
is  on  leave. 


If  the  user  desires  to  see  a  list  of  all  his  suspenses,  he  has 
several  ways  of  specifying  what  he  would  like  to  see.  If  he  enters  a  "Y” 
in  SUSPENSES  without  entering  anything  else  on  the  screen,  he  will  see  a 
list  of  all  suspenses  up  to  and  including  today's  date.  If  a  d.  te  other 
than  todays  had  been  entered  in  DATE  then  the  list  of  suspenses  etrieved 
from  CADIS  would  be  all  those  suspenses  up  to  and  including  the  oecified 
date.  If  a  value  had  been  entered  in  TYPE  then  only  suspenses  of  that 
particular  type,  up  to  and  including  whatever  date  was  in  DATE  would  be 
listed.  (Default  value  for  TYPE  is  blank,  resulting  in  all  lypes  of 
suspenses  being  retrieved,  subject  only  to  DATE  constraints.)  ATE  is  a 
seven  character  field  for  day,  month,  and  year,  e.g.  28  NOV  82. 

In  the  event  that  the  user  would  like  to  enter  data  concern  ng  a  new 
Cl  student  into  CADIS,  the  first  thing  he  must  do  is  to  create  a  new  stu¬ 
dent  header.  (As  a  by  product  of  entering  the  appropriate  data  nto  the 
new  student  header,  the  appropriate  minimal  data  is  obtained  o  create 
all  necessary  relations  for  the  new  student  in  CADIS.)  All  that  is 
required  to  Initiate  the  process  is  to  enter  a  "Y"  in  CREA  E.  This 
causes  SCREEN  1C,  the  create  new  student  screen,  to  be  displayed 

The  format  for  SCREEN  1C  is: 

ENTER  DATA  ON  NEW  STUDENT  IN  APPROPRIATE  FIELDS 

RANK  [  ]  NAME  (LAST,  FIRST  MI)  [ 

FULL  SSAN  (  j 

SCHOOL  [  )  PROGRAM  [  | 

ENTER  A  "Q"  IN  SSAN  TO  QUIT  WITHOUT  FINISHING  STUDENT  L  ADER 


If  the  user  would  like  to  process  an  individual  student,  he  roust 
enter  the  last  four  digits  of  the  student's  SSAN  into  the  SSAN  ileld  of 
SCREEN  1. 
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Finally,  If  the  user  desires  to  quit,  i.e.  leave  SCREEN  1  ai  i  return 
to  SCREEN  0,  then  he  enters  a  "Q"  In  QUIT. 

Assuming  that  on  SCREEN  1  the  user  had  elected  to  view  a  li  i  of  all 
suspenses,  the  next  screen  he  would  see  is  screen  1A,  th<  general 
suspense  list  screen. 


The  format  of  SCREEN  1A  is: 


AUTOMATIC  PACING  (Y/N):  [  j 

LAST  NAME,  FIRST  NAME  MI.  FULL  SSN  DATE  TYPE  ACTION 

LAST  NAME,  FIRST  NAME  MI.  FULL  SSN  DATE  TYPE  ACTION 


NOTE:  If  a  "Y"  is  entered  in  the  au lo  paging  field,  the  listing 

automatically  stops  after  one  screen  of  data  has  teen  displayed. 
To  start  the  listing  up  again  and  get  the  next  screen  of 
data,  simply  hit  “RETURN".  Entering  an  "N"  in  thi  auto 
paging  field  lets  the  listing  be  printed  out  continuously 
from  start  to  finish. 


In  the  event  that  the  user  had  decided  to  process  an  Individual  stu¬ 
dent  on  SCREEN  1,  it  is  possible  that  more  than  one  student  possesses  the 
same  last  four  digits  In  their  SSAN  as  well  as  also  being  the  responsi¬ 
bility  of  a  given  user  (PM).  If  this  does  happen,  then  the  user  will  see 
SCREEN  IB,  the  duplicate  student  screen. 


The  format  of  SCREEN  IB  is: 

ENTER  FULL  SSN  FOR  DESIRED  STUDENT  [  ] 

LAST  NAME,  FIRST  NAME  MI.  FULL  SSAN 

LAST  NAME,  FIRST  NAME  MI.  FULL  SSAN 

ENTER  A  "Q"  FOR  SSAN  TO  QUIT  WITHOUT  SELECTING  A  STUDEN* 


By  selecting  the  full  SSAN  of  the  student  desired  and  enter ; ng  it  on 
SCREEN  IB,  the  user  and  PSS  is  assured  of  processing  only  the  a  single 
correct  Btudent. 

Assuming  the  decision  to  process  an  individual  student  was  .nade  at 
SCREEN  l,  it  is  at  this  point  (l.e.,  a  single  student  has  beer  identi¬ 
fied)  that  PSS  builds  the  STUDENT  HEADER  (see  the  description  oi  a  STU¬ 
DENT  HEADER  above).  As  mentioned  previously,  for  all  subsequent  screen 
displays  Involving  this  student,  his  STUDENT  HEADER  will  be  tl  e  write 
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protected  top  portion  of  the  CRT  screen. 

For  processing  Individual  students  PSS  has  four  functions  v.  ich  can 
be  invoked  by  the  user.  SCREEN  2  shows  these  four  individua.  student 
functions  as  well  as  the  common  function  QUIT. 

The  format  for  SCREEN  2  is: 

(STUDENT  HEADER) 

A.  BIOCRAPHICAL  DATA 
■B.  EDUCATIONAL  PLAN 

C.  MEMO  FOR  THE  RECORD 

D.  SUSPENSES 
Q.  QUIT 

ENTER  YOUR  SELECTION:  (  ] 


NOTE:  The  commands  defined  earlier  in  the  functional  de  cription, 
apply  to  all  the  individual  student  fun>  cions  and 
screens  that  follow. 


If  the  user  enters  an  “A”  on  SCREEN  2,  the  next  screen  that  he  will 
see  is  SCREEN  3,  the  bio  data  screen. 
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The  format  for  SCREEN  3  Is: 
(STUDENT  HEADER) 


LINE  CMD 
1  (  1 

2  l  1 

3  [  ] 

4  [  ] 

5  (  1 

6  [  ] 

7  [  ) 

8  (  ] 

9  [  1 

10  (  ) 

11  l  1 

12  [  ] 

13  [  ) 

14  [  ] 

15  [  ] 

16  [  ] 

17  [  1 


GRADUATE  CPA  [  J  BEGIN  DATE  [  ]  ED  COL  1  | 

PROGRAM  MGR  [  j  CRAD  DATE  [  j  DEGREE  CODE  | 

ACADEMIC  STATUS  [  ]  CLASS  CODE  [  j  DEGREI.  GRANTED  [ 

ADVISOR  (  J  TR$-IN-DATE  (  j  DEPT-D  \TE  J 

MANNING  CODE  [  ]  TRS-OUT-DATE  [  ]  AVAIL- JATE  ( 

LAST  MAJCOM  [  j  DEPARTURE  REASON  { 

OUTPUT  MAJCOM  [  J  STATUS  [ 

PAFSC  [  ]  DUTY  TITLE  [ 

THESIS  PAY  (  ]  DUTY  PHONE  (  ]  [  ] 

U-GRAD  GPA  [  )  U-GRAD  SCHL  [ 

PRIOR  DEGREE  (  ]  PRIOR  AFIT  [  ] 

GRE  VERBAL  (  ]  QUANT  [  ]  TOTAL  [  ] 

GMAT  TOTAL  (  } 

DOR  (  ]  TMST  [  ]  AERO  BATING  [  ] 

DOB  (  ]  MARITAL  STATUS  [  )  ETHNIC  CROUP  [  ]  SEX  [  ] 

LOCAL  ADDRESS  [ 

HOME  PHONE  [  }  {  ]  STATE-OF-LECAL-RESIDENCE  [  ] 


NOTE:  ALL  CPA'S  SHOWN  ON  SCREEN  4  HAVE  BEEN  CONVERTED  TO  A  -4.0  SCALE 


Entering  a  "B"  on  SCREEN  2  results  in  SCREEN  4,  the  ed  pla.i,  being 
displayed.  When  SCREEN  4  is  first  displayed  on  the  CRT,  it  will  show  the 
current  term.  Paging  back,  i.e.,  entering  a  command  in  the  -VID  field 
of  LINE  1,  will  show  the  the  user  the  previously  completed  term(s).  Pag¬ 
ing  forward  from  the  original  SCREEN  4  displayed,  i.e.,  enterin’,  a  "+" 
command  in  the  CMD  field  of  LINE  1,  will  show  the  student's  planned 
schedule. 
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The  format  for  SCREEN  A  is: 


(STUDENT  HEADER) 


LINE  CMD 


1 

[  ) 

PROJECTED  GRADUATION 

DATE:  [ 

) 

2 

i  i 

DATE  OF 

LATEST  APPROVED  ED  PLAN: 

(  1 

TERM  # 

TERM 

START  DATE 

TERM  STOP 

DATE 

TERM 

TYPE 

3 

[  ] 

l  1 

l 

]  . 

[ 

] 

l 

] 

COURSE 

COURSE 

COURSE 

COURSE 

Ci.  bIT 

GRADE 

ID 

DEPT 

NUM 

TITLE 

i.  .s 

A 

i  i 

[  1 

[  ] 

l 

1  ( 

1 

[  1 

[  ] 

5 

• 

(  i 

l  '  1 

i  ) 

l 

1  t 

] 

l  ) 

[  ) 

• 

n 

[  ) 

I  ) 

(  ] 

I 

1  [ 

] 

1  1 

l  1 

TOTAL  TERM 

HRS 

I  1  CPA 

(  ] 

If  a 

"C” 

had  been 

entered 

on 

SCREEN  2,  then  SCREEN  5 

,  the 

emo 

for 

record  screen  (MFR) ,  will  be  displayed. 


ef* 


The  format  for  SCREEN  5  is: 

(STUDENT  HEADER) 

LINE  CMD  DATE  MEMO 

1  l  1  (  11 

l 

2  [  ]  [  1  [ 

l 

3  111  11 


NOTE:  MFR'S  are  considered  as  one  record  per  two  lines,  ev  n  though 
they  are  displayed  on  two  lines.  When  the  end  of  th  first 
block  is  reached,  the  terminal  will  automatically  Ju  ip  to  the 
next  block. 


Assuming  the  user  had  entered  a  "D"  on  SCREEN  2  then  SCREE:  6,  the 
Individual  student's  suspense  screen,  is  displayed. 
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The  format  for  SCREEN  6  Is: 


(STUDENT  HEADER) 


LINE  CMD  DATE  TYPE 

1111  1  l  1  l 

2  M  (  111  I 

3(11  111  1 


n  (  1  (  111  l 


ACTION 
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MODULE  DESCRIPTIONS  FOR  THE  AFIT/CIR/M 
PERSONNEL  SUBSYSTEM  SOFTWARE  (PSS) 


Further  information  on  any  of  the  menus  or  displays 
can  be  found  in  the  Functional  Description  (FD)  of  PSS, 
APPENDIX  I IIC. 


MODULE  1 

************************************************************  ****** 


* 

*NAME:  AUTHORIZATION/ACCESS  CHECKINC 

* 


* 

* 

* 


♦FUNCTION:  Displays  SCREEN  0;  Checks  for  proper  database  pas;  word  * 
*  and  Cl  users  ID;  Routes  users  to  proper  subsystem  (PS!  /FSS)* 

♦INPUT:  DATABASE  PASSWORD  AND  Cl  USER  ID  * 

♦OUTPUT:  UID  (Cl  users  ID),  PW  (Database  Password)  ♦ 

************************************************************  ,■  ****** 

PROCEDURE: 

TO  BE  DEVELOPED  (TBD) 


MODULE  2 

************************************************************ >  ****** 


*  * 

♦NAME:  FINANCIAL  SUBSYSTEM  (FSS)  * 

*  * 

♦FUNCTION:  See  APPENDIX  IIIG  * 

*  * 

♦INPUT:  ♦ 

♦OUTPUT :  * 


************************************************************ .  ****** 

PROCEDURE: 


MODULE  3 

************************************************************ »  ****** 
* 

♦NAME:  Personnel  Subsystem  (PSS) 

* 

♦FUNCTION:  Driver  for  entire  Personnel  Subsystem  Software; 

*  Displays  SCREEN  1 

♦INPUT:  UID,  PW 

♦OUTPUT:  UID,  PW,  SHORTSSAN  (last  4  digits  of  SSAN) 

*************************************************************  ****** 
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PROCEDURE : 

Begin 

HALT  •  false 
While  not  HALT  do 
Begin 

Print  SCREEN  1 
SCREEN  -  "1” 

Repeat 

Call  Get_Inppt  (SCREEN, INPUT, DONE) 

Call  Validate_lnput  (INPUT, AMV.VALIDIN  T) 

If  not  VALIDINPUT  then 
Call  Flag_Errors  (AMV) 

Endif 

Until  DONE  &  VALIDINPUT 

Case  (nonblank.  &  validated)  INPUT  of  fiel  . 

1.  PM  not  •  (last  2  char,  of  U1D):  Call  ::>ange  PM 
(UID) 

2.  SSAN  &  PM:  begin 

Call  Get_Full_S SAN (SHORT  SAN, 

UID, PW.FULLSSANLIST, SSAN  >UNT, 
SSAN) 

If  SSANCOUNT  >  1  then 
Call  Process_Dupl icatc 
Students  (UID, PW, FULLS  wN’LlST, 
SSANCOUNT , FULLS  SAN ) 

Endif 

If  SSANCOUNT  >-  1  then 

Call  Build  Student  He  lur( 

UK',  PW  .  FULUSSAN ,  SHR )  ;  SHR 
means  "Student  Header  tecord” 
Call  Process_Student(  1D,PW, 
SHR) 

Endif 
End( 2 ) 

3.  Suspense  &  Date  &  Type:  Call  Proces;  eneral 
Suspenses(UID, PW , DATE, TYPE ) 

4.  Create  *  "Y":  Begin 

C3II  Create_New_Studi  :(PW,UIU, 
SHR) 

Call  Build_Student_Hc  ier(UID, 
PW, FULLS SAN, SHR) 

CALL  Process  Student (  lU,PW,Sit;\ 
Lnd(4 ) 

5.  Quit"  "Q":  HALT  *  true 
Endcase 

End(while) 

End  (main) 
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MODULE  4 

********************************************************** ** 
* 

♦NAME:  Change_PM 

* 

♦FUNCTION:  To  change  Cl  users  ID  w/o  backing  up  to  Module  1 

* 

♦INPUT:  UID 
♦OUTPUT:  UID 

************************************************************. 
PROCEDURE:  TBD 


MODULE  5 

************************************************************  <■ 
* 

♦NAME:  Create_New_Student 

* 

♦FUNCTION:  To  enter  a  new  Cl  student  into  the  database;  Creai 
♦  and  Display  STUDENT  HEADER 

♦INPUT:  PW.UID 

♦OUTPUT:  SHR  (Student  Header  Record) 

************************************************************’ 

PROCEDURE: 

Begin 

Print  out  SCREEN  IC 
Repeat 

Call  Cct_Input( SCREEN, INPUT, DONE) 

Call  Validate_Input( INPUT,AMV, VALIDINPUT) 

If  not  VALIDINPUT  then 

call  Flag_Errors  (AMV);  note  AMV*"appropriate  modul. 
Endlf 

If  SSAN-  ”Q”  then 

DONE*  true;  note,  Validate_Input  accepts  "Q"  as  a  v. 
Endlf 

Until  DONE  &  VALIDINPUT 
If  SSAN  not  -  "Q"  then 
Send  data  to  database 

Store  data  in  SHR;  SHR-”Student  Header  Record” 

Endlf 
End  (main) 


.****** 

* 

* 

* 

* 

* 

* 

* 

A  *****  * 


N  **  A  *** 

A 

A 

* 

A 

A 

* 

A 

<  ****** 


variable 

lid  SSAN 
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MODULE  6 

***  ***  A****  A  ******  ***  it  ********  ***  ******  A  A***  A*  A*  A*  **  A  A*  A**  *rt  ■  ******* 


*  * 

*NAME:  Build_Student_Header  * 

*  * 

‘FUNCTION:  Build  and  Display  the  STUDENT  HEADER  * 

*  * 

‘INPUT:  U ID, PW, FULLS SAN  * 

‘OUTPUT:  S11R  (Student  Header  Record)  * 


************************************************************ .  ******* 
PROCEDURE: 

Begin 

If  the  £>HR  for  this  student  doesn't  already  exist  then 
Retrieve  data  from  database 
Store  data  in  SHR 
Endif 

Print  out  the  STUDENT  HEADER 
End  (main) 


MODULE  7 

************************************************************  ******* 


*  * 

‘NAME:  Process_Student  * 

*  * 

‘FUNCTION:  Driver  for  individual  student  management  modules;  * 

*  Display  SCREEN  2  * 

‘INPUT:  UID.PW.SHR  (Student  Header  Record)  * 

‘OUTPUT:  UID.PW.SHR  * 


************************************************************  ******* 
PROCEDURE: 

Begin 

Print  out  SCREEN  2 
SCREEN  ■"2" 

Repeat 

Call  Get_Input  (SCREEN, INPUT, DONE) 

Call  Validate_Input  (INPUT, AMV, VAL-DINPUT) 

If  not  VALIDINPUT  then 

Call  Flag_Errors  (AMV);  note  AMV«"appropr late  modul.  variable 
Endif 

Until  DONE  &  VALIDINPUT 
Case  Input  of 

1.  "A" :Call  Process_Bio_Da ta(U ID, PW, FULLS SAN) 

2.  ”B":C all  Process_Ed_Plan(UID,PW,FULLSAN) 

3.  "C" :Cal 1  Process_Memo_For_Record(UID,PW,FULLSSAN) 

4.  “D":Call  Process_lndividual_Suspense(UID, PW .FULLSS  ) 

5.  ”Q“:Null;  no  action,  fall  to  end  of  procedure  &  rei arn 

to  module  3 

Endcase 
End  (main) 
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MODULE  8 

************************************************************  X ****** 


*  * 

‘NAME:  Process_Ceneral_Suspenses  * 

*  * 

‘FUNCTION:  Display  SCREEN  1A;  Retrieve  and  Display  ALL  the  * 

*  outstanding  suspenses  of  a  particular  type  (TYPE  .  j  be  * 

*  determined)  for  ALL  students  * 

‘INPUT:  UID.PW, DATE, TYPE  * 

‘OUTPUT:  None  * 


************************************************************  * ****** 

PROCEDURE: 

Begin 

Print  out  SCREEN  1A 
SCREEN  -  "1A" 

Repeat 

Call  Ce t_In put (SCREEN, INPUT , DONE ) 

Call  Validate_Input( INPUT, AMV, VALIDINPUT) 

If  not  VALIDINPUT  then 

call  Flag_Errors(AMV) ;  AMV“"appropriate  module  vari.  hies" 
Endif 

UntK  DONE  &  VALIDINPUT 
If  INPUT  -  “Y"  then 
Repeat 

If  (Screen  isn't  full)  then 

Retrieve  data  from  the  database 
Else 

call  Get_Char( INPUT) 

Until  (no  more  data) 

Else 

Repeat 

Retrieve  data  from  the  database 
Until  (no  more  data) 

End  (main) 


MODULE  9 

************************************************************  ^ ****** 


* 


* 


*  NAME :  Ce  t_Fu 1 1_S  SAN  * 

*  ★ 

‘FUNCTION:  Retrieve  all  SSAN's  from  the  database  whose  last  * 

*  digits  -  SHORTSSAN  &  where  the  SSAN  is  in  the  UIl  *  * 

*  view  * 

‘INPUT:  SHORTSSAN, PW,UID  * 

‘OUTPUT:  FULLSSANLIST , SSAN , SSANCOUNT  * 

************************************************************  x****** 


PROCEDURE: 

Begin 

SSANCOUNT  -  0 
Repeat 

Retrieve  data  from  the  database 
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Put  data  into  FULLSSANLIST 
Increment  SSANCOUNT 
Until  (no  more  data) 

If  SSANCOUNT  <  1  then 

Call  Flag_Errors(AMV) ;  AMV*"appropriate  module  variables 
End  if 
End  (main) 


MODULE  10 

*************************************************************  X****** 
*  * 

♦NAME:  Process_Duplicate_Students  * 

*  * 

♦FUNCTION:  Display  SCREEN  IB;  Retrieve  &  Display  data  on  all  * 

*  students  who  have  the  same  last  4  digits  as  those  * 

*  digits  entered  into  SSAN  on  SCREEN  1;  Get  the  full  * 

*  SSAN  of  the  single  student  the  user  desires  to  pro  ess  * 

♦INPUT:  UID.PW, FULLSSANLIST, SSANCOUNT  * 

♦OUTPUT:  FULLSSAN,  SSANCOUNT  * 

*************************************************************  ****** 

PROCEDURE: 

Begin 

Print  SCREEN  IB 

For  I  -  1  to  SSANCOUNT  do 

Retrieve  data  for  student  whose  SSAN  *  Ith  SSAN  in 
FULLSSANLIST 
Print  out  data 
Endfor 

SCREEN  -  "IB" 

Repeat 

Call  Get_Input( SCREEN, INPUT, DONE) 

Call  Validate_Input(INPUT,AMV, VALID1NPUT) 

If  not  VALIDINPUT  then 
Call  Flag_Er rors( AMV) 

End  if 

If  INPUT  -  "Q"  then 

DONE  ■  true;  Validate_Input  accepts  "Q”  as  valid 
F.ndif 

Until  DONE  &  VALIDINPUT 
End  (main) 
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MODULE  11 

************************************************************ .  :****** 


*  * 

‘NAME:  Process_Bio_Data  * 

*  * 

‘FUNCTION:  Display  SCREEN  3;  Retrieve  &  Display  Biodata;  Drr.  •  * 

*  Module  15  * 

‘INPUT:  UID, PW .FULLSSAN  * 

‘OUTPUT:  CMD,UID,PW,FULLSSAN  (CMD  is  the  line  command  variab.  ■)  ‘ 


************************************************************ „  .****** 
PROCEDURE: 

Begin 

HALT-  false 
While  not  HALT  do 
Repeat 

retrieve  data  from  the  database 
Until  (no  more  data) 

Print  out  SCREEN  3 
SCREEN  -  “3” 

Repeat 

Call  Cet_Input( SCREEN, INPUT, DONE) 

Call  Validate_Input( INPUT, AMV, VALIDINPUT) 

If  not  VALIDINPUT  then 

Call  Flag_Er rors( AMV) ;  AMV-”appropriate  module  variables" 
End  if 

Until  DONE  &  VALIDINPUT 

;  NOTE:  If  any  line  commands  were  entered  on  SCREEN  3  then  C(  c_Input  L 
Validate  Input  will  have  assigned  a  valid  value  to  e.  >:h  line 
command  XCMD) 

Repeat 

If  (CMD  not  -  “  ")  &  (CMD  not  -  "Q")  then 

Call  Process_Line_Command(UID, PW, FULLS SAN, CMD, SCR:  :N) 

Endif 

Until  (All  line  commands  have  been  processed)  or  (CMD  =  "Q") 

If  CMD  -  “Q”  then 
HALT  -  true 
Endif 
Endwhile 
End  (main) 
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MODULE  12 

*******  *****************************************************  .  A*  **  *** 


*  * 

♦NAME:  Process_Ed_Plan  * 

*  * 

♦FUNCTION:  Display  SCREEN  A;  Retrieve  &  Display  Ed  Plan  data:  * 

*  Drive  module  15  * 

♦INPUT:  UID, PW , FULLS SAN  * 

♦OUTPUT:  CMD,  UID,  PW,  FULLSSAN  (CMD  is  -he  variable  for  li:  ,•  * 

*  command  values)  * 


************************************************************  ******* 

PROCEDURE: 

Same  as  module  11  except  replace  "SCREEN  3”  references  wi  u 
"SCREEN  A"  references  where  appropriate 


MODULE  13 

*  A* ****************** ******************************  *********-.  ******* 


*  * 

♦NAME:  Process_Memo_For_Record  ♦ 

*  * 

♦FUNCTION:  Display  SCREEN  5;  Retrieve  &  Display  MFR  data  * 

*  * 

♦INPUT:  UID, PW, FULLSSAN  * 

♦OUTPUT:  CMD, UID, PW, FULLSSAN  (CMD  is  the  variable  for  line  * 

*  command  values)  * 


************************************************************  ******* 
PROCEDURE: 

Same  as  module  11  except  replace  "SCREEN  3"  references  wi i  'i 
"SCREEN  5"  where  appropriate 


MODULE  1A 

************************************************************  ,  .<* ***** 


*  * 

♦NAME:  Process_Individual_Suspense  * 

*  * 

♦FUNCTION:  Display  SCREEN  6;  Retrieve  &  Display  suspense  dat.  for  * 

*  an  individual  student;  Drive  module  15  * 

♦INPUT:  U I D,PW, FULLSSAN  * 


♦OUTPUT:  CMD, UID, PW, FULLSSAN  (CMD  is  the  variable  for  line  o  nmand  * 
*  values)  * 

************************************************************  .  .>****** 

PROCEDURE: 

Same  as  module  11  except  change  "SCREEN  3"  references  to  '  -CREEN 
6"  where  appropriate 


Appendix  IlID 


PACE  8 


MODULE  15 

ft***********************************************************/  * ****** 
*  * 

♦NAME:  Process_Line_Comraand  * 

*  * 


♦FUNCTION:  Drive  the  line  command  processor  modules  * 

*  * 


♦INPUT:  UID, PW.FULLSSAN.CMD, SCREEN  (see  module  14  for  CMD  e  plain)* 
♦OUTPUT:  UID, PW.FULLSSAN, SCREEN  * 
* *********************** ************************************>  *  ****** 


PROCEDURE: 


Begin 

Case  CMD  of 


1. 

2. 

3. 

4. 

5. 

6. 


Call 

Call 

Call 

Call 

Call 

Call 


Endcase 


Page_Forward (UID, PW.FULLSSAN, SCREEN) 
Page_Back(UID, PW.FULLSSAN, SCREEN) 
Change_Record(UID, PW.FULLSSAN) 
Delete_Record( UID, PW.FULLSSAN) 
Select_Record(UID, PW.FULLSSAN) 

Create_Nev  Record (UID, PW.FULLSSAN, SCREEN 


End  (main) 


MODULE  16 

************************************************************  A  ****** 
*  * 

♦NAME:  Create_New_Record  * 

*  * 

♦FUNCTION:  Display  appropriate  basic  screen  with  no  data;  * 

*  Receive  new  data  from  keyboard;  Transmit  data  to  d  cabase* 

♦INPUT:  UID, PW.FULLSSAN, SCREEN  * 


♦OUTPUT:  None  * 

it  ********  ********************  *  **  *******  *****  ★  **  **  ****  ****  A  A  A  A  A  A  A 

PROCEDURE: 

Begin 

Print  appropriate  screen 
Repeat 

Call  Get_Input(SCREEN,  INPUT,  DONE'* 

Call  Validate_Input  (INPUT, AMV , V< .  - i DI NPUT ) ;  NOTE:  LIN  C.lD’s 
If  not  VALIDINPUT  then  ;  except  "Cj"  no 

Call  Flag__Errors(  AMV)  ;  accepted 

End  if 

If  (VALIDINPUT)  &  (INPUT  not  -  "Q")  then 
Transmit  data  to  database  as  appropriate 
End  if 

If  INPUT  -  "Q”  then 

DONE  *  true;  Validate_Input  accepts  "Q”  as  a  valid  iput 
End  if 

Until  DONE  &  VALIDINPUT 
End  (main) 
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MODULE  17  &  18 

*  *******************  ***  A*  *******  **  *  A*  A  *******  A  ***  ***********  A  *****  * 


*  * 

•NAME:  Page_Forward/Back  * 

*  * 

•FUNCTION:  Show  next/ previous  page  of  data  of  screen  current  y  * 

*  being  displayed  * 

•INPUT:  UID,PW,FULLSSAN, SCREEN  * 

•OUTPUT:  None  * 


*****************************************..  ******************  ******* 

PROCEDURE: 

Begin 

Cec  Nexf/Previous  page  of  data 
Print  appropriate  screen 
End  (main) 


MODULE  19,20,21 

*  ******************************************************** **X  ******* 

*  * 

•NAME:  Change/Delete/Select_Record  * 

*  * 


•FUNCTION:  Change/Delete/Select  appropriate  record  on  the  sc  con  * 
*  and  in  the  database;  Update  screen  display  as  nec  ssary  * 

•INPUT:  U ID, PW, FULLS SAN  * 

•OUTPUT:  None  • 

****************************************».. ******************  k ****** 

PROCEDURE: 

TBD 


MODULE  22 

************************************************************  ******* 


•NAME:  Get_Input 

* 

•FUNCTION: 

* 

* 

* 

* 

•INPUT: 

* 

* 

* 

* 

* 


This  is  a  submodule  which  is  different  in  specif: 
details  for  each  module  which  uses  it,  but  is  ver 
similiar  in  function.  It  gets  a  line  of  input  fr 
screen  &  assigns  the  input  to  the  appropriate  var 
for  a  given  line  of  that  screen 
SCREEN, INPUT, DONE  (SCREEN  indicates  which  screen  dis 
is  being  used,  DONE  is  a  boolean  variable  set  to  tru 
Cet_Input  when  all  the  variables  associated  with  a  p 
screen  have  been  assigned  values  (all  input  from  the 
has  been  read  in),  INPUT  is  a  temporary  variable  use 
hold  input  from  the  screen). 

•OUTPUT:  NONE 

************************************************************ 


* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 

A  *  ***** 


.it  a 
a  b  1  e  s 

lay 
by 
ven 
c  re  e  n 
to 


PROCEDURE: 

TBD 
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Validate_Input 


MODULE  23 

**** ****** ************** ******** ********* / ****************** 
* 

*NAME : 

* 

♦FUNCTION 

* 

* 

* 

* 

* 

* 

♦INPUT: 

* 

* 

* 

* 

♦OUTPUT 


A  submodule  which  Is  different  in  detail  for  each 
module  that  uses  it,  but  is  similar  in  function  1 
all  of  them.  This  module  validates  that  the  inpu. 
a  given  field  for  a  given  screen  is  correct  in  fo 
range,  type,  etc.  as  desired.  This  could  be  done 
referencing  the  data  dictionary  and  other  appropr 
sources . 

INPUT', VALIDINPUT.AMV  (VALIDINPUT  is  a  boolean  variab. 
which  is  set  to  true  if  the  input  for  a  given  AMV  is 
and  which  is  set  to  false  otherwise.  AMV  refers  to  a 
riate  module  variable.  INPUT  is  a  temporary  var.  us* 
reading  in  data.) 

VALIDINPUT 

************************************************************ 

PROCEDURE: 

TBD 


******* 

* 

* 

* 

* 

* 

trora  * 
iat,  * 

•>y  * 

ite  * 
* 
* 

/a lid  ♦ 
,jrop~  * 
1  for  ♦ 

* 

* 

<  ****** 


MODULE  2 A 

************************************************************  x****** 

*  * 

♦NAME:  Flag_Errors  ♦ 

*  * 

♦FUNCTION:  This  submodule  is  different  in  detail  for  every  m  iule  ♦ 

*  which  uses  it,  but  is  very  similiar  in  function.  Ibis  ♦ 

*  module  would  be  designed  to  print  out  appropriate  error  * 

*  messages  in  the  ERROR  FOOTER  at  the  bottom  of  the  ,>age  * 

*  and  to  then  return  the  cursor  to  the  point  of  the  error.* 

♦INPUT:  AMV  (appropriate  module  variables)  * 

♦OUTPUT:  None  * 

************************************************************>  V  ***  *** 

PROCEDURE: 

TBD 


Ap  pe  nd  lx  HID 
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MODULE  25 

************************************************************  ******* 
*  * 

*NAM£:  Get  Char  * 

*  * 

*FUNCT10N:  Cets  one  character  from  the  terminal.  Maintains  *  rogram* 

*  control,  and  waits  doing  nothing  until  a  char,  is  input  * 

*  Does  nothing  with  the  char.  &  then  returns  to  cal. ing  * 

*  program.  * 

*INPUT :  INPUT  * 

♦OUTPUT :  None  * 

************************************************************  ******* 

PROCEDURE:  * 

TBD 


OTHER  AREAS  WHICH  WILL  NEED  TO  BE  DEVELOPED  DUE  TO  INSUFFI¬ 
CIENT  DATA  AT  THIS  TIME: 

Procedures  to  get  next/previous  page  of  data  Procedures  to 
retrieve/transmit  data  to/from  the  database 


0*~ 
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A  FUNCTIONAL  DESCRIPTION  OF  THE 


AFIT/CIV  FINANCIAL  SUBSYSTEM  (FSS)  SOFTWARE 


The  following  is  a  description  of  the  AFIT/CIV  Financial  S  ibsystem 
(FSS)  from  the  users  standpoint.  For  each  menu  which  requests  tie  user 
to  choose  a  function,  the  user  has  only,  to  type  the  letter  of  th  func¬ 
tion  he  wishes  to  perform.  Upon  doing  this,  the  program  will  pro  ide  the 
appropriate  responses.  Error  messages  for  such  things  as  .  invali  input 
or  entering  a  letter  which  is  not  displayed  ^tinted  at  the  1  itom  of 
each  screen  and  the  user  is  given  a  chance  to  try  again.  The  program 
will  continue  to  do  this  until  a  valid  response  is  entered. 

At  every  level,  the  quit  or  'Q'  will  allow  the  user  to  stop  he  the 
current  operation  and  return  to  the  previous  menu.  Users  must  b.!  k  their 
way  out  of  the  system  one  menu  at  a  time.  They  also  have  the  opportunity 
to  go  back  and  do  something  different. 

The  security  and  entry  procedures  for  the  FSS  are  identical  o  those 
used  in  the  Personnel  Sub  System  (PSS).  Further  information  ah  >ut  this 
procedure  can  be  obtained  by  referring  to  appendix  IIIC. 

The  two  displays  STUDEOT  HEADER  (Dl)  and  SCHOOL  HEADER  (D.),  are 
displayed  depending  on  whether  the  user  is  performing  a  student  01  school 
operation.  These  headers  are  displayed  as  protected  fields  and  cannot  be 
directly  changed  by  the  user. 

In  the  update  programs  the  display  is  initialized  with  the  c.irsor  in 
the  function  column  (FUN)  of  the  first  line.  The  user  has  only  to  move 
the  cursor  up  or  down  to  the  line  that  is  to  be  updated  , enter  th  •  proper 
function  (A,  Add;  C,  Change;  or  D,  Delete)  and  move  the  cursor  to  the 
begining  of  the  field(s)  he  wishes  to  modify.  Once  finished,  t  >o  user 
transmits  the  line  and  the  program  will  edit  each  field  according  to 
predefined  criteria  (e.g.  SSAN  is  all  numeric).  The  first  item  checked 
is  the  line  number.  If  this  has  been  changed  or  is  unrecogniz.i  >le,  the 
program  will  harshly  notify  the  user  and  restore  the  line  to  its  original 
format.  If  the  user  is  updating  line  3  of  a  ten  line  dispiay,  for 
instance,  and  changes  the  line  number  to  6;  the  update  program  will  think 
he  is  operating  on  line  6  and  make  erroneous  changes.  THE  USER  iUST  NOT 
CHANCE  THE  LINE  NUMBERS  or  the  results  cannot  be  predicted. 

Errors  in  the  update  programs  are  handled  just  like  any  otho.  error 
and  are  displayed  at  the  bottom  of  each  page.  The  line  is  scan  iod  from 
left  to  right  and  one  message  is  displayed  for  each  error.  .on  the 
first  error  is  detected,  the  program  stops  and  prints  the  mes  .age  and 
terminates  scanning.  Therefore,  if  a  user  lias  three  errors  in  a  ine  he 
will  get  three  separate  error  messages  and  have  to  make  three  Ranges. 
The  software  does  not  search  for  all  errors,  at  one  time,  but  simply 
notifies  the  user  of  the  first  one  it  finds. 
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Upon  entering  the  system,  through  the  proper  security  pi  icedures 
described  earlier,  the  user  will  first  be  presented  with  the  i  allowing 
menu: 

MENU  VI:  CHOOSE  THE  FUNCTION  TO  BE  PERFORMED:  [  ] 

A:  STUDENT  PAYMENTS 
B:  SCHOOL  PAYMENTS 
Q:  QUIT 


At  this  point  the  user  must  choose  whether  he  will  operate  <n  stu¬ 
dent  information,  school  information  or  quit  altogether. 


Should  the  user  desire  choose  a  student  operation,  he  will  1  asked 
to  enter  the  full  SSAN  of  the  student  using  menu  V2. 


MENU  V 2:  PROCESS  A  STUDENT 

ENTER  STUDENTS  FULL  SSAN  j  ] 


Once  a  student  has  been  retrieved  from  the  database,  the  sy;  tern  will 
display  the  student  header  format  (Dl)  for  each  operation  deai ing  with 
that  student.  The  user  may  not  change  this  header  directly. 


Dl:  STUDENT  HEADER 

SSAN  RANK  NAME  MAF  FUND_TYPF. 

ADDRESS  SCHOOL  START_DATE  CRAD_DATE 

PM  TEKM_TYPE 

STATE  OF  LECAL  RES  PHONE 


EXAMPLE : 

999-55-1234  2LT  DIMWITTER,  JONATHAN  I.  POCAY  FUNDED  LE>  -L 

1234  HOLE  BLVD  PODUNK  UNIVERSITY  3  JAN  51  22  DEC  99 

ROOM  125  CIRW  SEM 

MOOSEJAW,  W1  00001  ND  (111 )-l 23-33A5 


After  the  student  header  is  displayed,  the  user  can  next  specify 
whether  he  wants  to  work  on  the  invoices  paid  for  that  student  >  siciply 
look  at  a  list  of  the  costs/expenses  Incurred  on  behalf  of  that  tudent, 
to  date.  Menu  V2.1  will  also  let  the  user  go  back  and  identif  another 
student  to  process. 
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MENU  V2.1:  SELECT  THE  OPTION  TO  PROCESS 


STUDENT  HEADER  (Dl) 

SELECT  THE  DESIRED  FUNCTION  TO  BE  PERFORMED  {  ) 
A:  UPDATE/ EXAMINE  INVOICES 
B:  EXAMINE  STUDENT  COSTS 
C:  EXAMINE  ANOTHER  STUDENT 
Q:  QUIT 


Should  Che  user  desire  Co  examine  or  updaCe  Che  invoices  or  che 
scudenc,  Che  daca  will  be  displayed  in  Che  formac  of  menu/displa^  V2.1.1. 
This  is  Che  basic  formac  for  all  of  Che  updaCe  programs,  wich  cl  vari¬ 
able  daca  being  placed  wichin  a  sec  of  brackecs  ([  ])  and  error  cssages 
prinCed  ac  Che  boCCom  of  Che  display.  The  brackecs  rcsCric"  '  e  of 
Che  inpuc  field  and  give  che  user  an  idea  as  Co  how  large  ic  is.  If  for 
some  reason  chere  are  Coo  many  lines  Co  display  on  a  single  sen  n,  che 
user  will  be  able  Co  "page"  Chrough  chem  by  encering  a  "+“  or  '  •"  under 
Che  funedon  column.  This  will  move  Che  display  forward  (+)  or  >ackward 
(-)  one  screenfull. 


QT 


MENU  V2.1.1:  UPDATE/ EXAMINE  STUDENT  INVOICES 
STUDENT  HEADER  (Dl) 

VO UC HE R_N UM BE R  V0UCUER_AM0UNT  PMTjCODE  INCLUSI\  _DATES 

DATE_POSTED  AMOUNT_REQUESTED  TERM_TYPE  HE.1  '.RES 

LINE  FUN 


1  111 

l 

2  [It 

l 


)  91  ) 

$[ 

I  9[  I 

$1 


[  )  ( 

(  1  t 

[  1  ( 

[  1  I 


) 

1 

1 

] 


EXAMPLE 

VOUCHER_NUMBER 

DATE_POSTF.D 

LINE  FUN 


VOUCHER_AMOUNT  PHT_CODE 
AMOUNT  REQUESTED  TERM  TYPE 


INCLUST  ._DATES 
RE  ClKS 


l 


|  )  [ 1 23456789AH] 

[15JAN80] 


$[123456.00] 

$[987654.99] 


[FEES]  [01JAN80-  .2MAR81 ] 
[SEM]  [ ASK1NC  T  <  MUCH  ] 


Should  Che  user  desire  Co  examine  che  various  coses  accrued  by  che 
sCudenC,  he  can  insCead  selecc  opcion  E  from  menu  V2.1  an  gee  che 
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following  display*  This  does  not  produce  an  updateable  displ  ;  nenu 
V2.1.2  displays  only  the  student  costs.  The  user  simply  sc  cts  the 
cost,  the  options  are  erased  and  the  retrieved  data  is  displayed 


MENU  V2.1.2:  EXAMINE  STUDENT  COSTS 
STUDENT  HEADER 

SELECT  THE  DESIRED  STUDENT  COSTS 
A:  TUITION 
B :  LABRATORY 

C :  BOOKS 


Q:  QUIT 
D2 :  STUDENT  COSTS 
STUDENT  HEADER 

COST  TYPE  SCCA  FY82  FY81  FY80  FY79  IAL 


dr 


TUITION  [  ]  (  )  [  ]  [ 

LABRATORY  [  )  [  ]  (  ]  [ 

BOOKS  |  ]  (  ]  [  ]  [ 


1  [  ] 

1  [  1 

]  l  ) 


] 

) 

] 
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If  the  user  had  chosen  option  B  from  menu  VI,  he  would  be  erating 
on  information  concerning  a  school  instead  of  a  student.  After  ntering 
option  B,  the  a  menu  will  appear  (menu  V3)  which  will  allow  the  ser  to 
select  the  particular  school  he  wishes  to  see. 

At  this  point,  the  user  may  enter  the  exact  name  of  the  schi  >1  (e.g. 
AUBURN  UNIVERSITY)  or  simply  enter  the  two  letter  state  abbrevi.  Lon  and 
a  list  of  schools  will  be  generated.  The  user  may  then  choose  ;  school 
from  the  list  and  continue.  If  an  incorrect  name  is  entered,  tin  program 
will  attempt  to  find  it  then  return  with  an  error  message,  menu  V3  and 
let  him  try  again. 

Menu  V3  will' allow  the  user  to  select  the  name  of  the  si  >ool  he 
desires . 

MENU  V3:  SELECT  THE  SCHOOL 

ENTER  ONE  OF  THE  FOLLOW INC: 

A:  SCHOOL  NAME  [  ] 

B:  SCHOOL  STATE  (  ] 

Q:  QUIT  [  ] 


If  the  user  requests  a  list  of  schools  in  a  particular  stai  •,  menu 
V3.1  will  appear  and  allow  him  to  select  a  school  fr am  the  li;  : .  This 
name  will  be  automatically  transferred  to  the  routine  which  will  , -Btrieve 
the  school  data. 

MENU  V3.1:  CENERATE  SCHOOL  LIST 


SELECT  THE  DESIRED  SCHOOL 

LINE  FUN  SCHOOL  NAME 

1  (  1  ( 

2  111 

3  111 

U  l  1  IQUIT1 


1 

1 

1 


« 


Once  a  school  has  been  selected,  the  system  will  auto  .clcally 
display  a  school  header  which  contains  certain  information  per  ment  to 
the  school.  This  header  (D3)  cannot  be  changed  directly  by  the  .i-r  and 
remains  on  the  screen  throughout  the  operations  for  that  school. 


Reproduced  from 
best  available 


copy. 


Appendix  1 1  IF 


PAGF.  5 


DISPLAY  D3:  SCHOOL  HEADER 
SCHOOL_NAME  ESA_NUMBER 

ADDRESS  SCHOOL  TYPE  TERM  TYPE 


EXAMPLE : 

AUBURN  UNIVERSITY  123456789ABCD 

AUBURN,  ALABAMA  36530  S  QTR 


Next  the  user  will  be  able  to  select  the  exact  function  he  v  >-,hes  to 

perforin  with  respect  to  the  chosen  school.  Each  update  progr  i  works 
exactly  like  those  for  the  student.  School  functions  may  be  cho;  n  using 
menu  V 3.2.  Options  C,  D  and  E  may  only  be  visable  to  those  ut  rs  with 
sufficient  access. 


MENU  V3.2:  SELECT  SCHOOL  FUNCTION 
SCHOOL  HEADER  (D3) 

SELECT  THE  DESIRED  FUNCTION  TO  BE  PERFORMED:  [  ] 
A:  UPDATE/ EXAMINE  INVOICES  AND  VOUCHERS 
B:  UPDATE/ EXAMINE  POINTS  OF  CONTACT 
C:  UPDATE/ EXAMINE  COST  MATRIX 
D:  PRODUCE  COST  FORCASTS 
E:  PRODUCE  CURRENT  COSTS 
Q:  QUIT 


If  the  user  chooses  option  A  from  menu  V3.2,  he  will  be  ble  to 
update  and  examine  all  the  vouchers  and  invoices  for  the  scht.  >1  along 
with  all  the  detailed  information  relevant  to  them.  Menu  V3.2.1  ill  be 
used  to  display,  in  an  update  format,  the  uirrcnt  invoice  dai  in  the 
database  for  the  school.  The  user  will  be  able  to  add,  change  oi  delete 
information  as  required. 
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MENU  V3.2.1:  UPDATE/ EXAMINE  INVOICES  AND  VOUCHERS 


SCHOOL  HEADER  (D3) 

INVOICE  NO 
VOUCHER_NO 

LINE  FUN 


1 


[  1  [ 
(  ] 


DATE_REC'D  INVO ICE_AMOUNT  TERM_TYPE  TE' 
DATE  PAID  AMOUNT  PAID 


DATES 


1  [ 

1 

1  ( 


$1 

$[ 


$.f 

n 


[  i  [ 
[  ]  i 


Mi 


s  o 


i , 

i 


1 

r  - 


EXAMPLE : 

SCHOOL  HEADER  (D3) 

INVOICE_NO  DATE_REC'D 
VOUCHERJ.'O  DATE_PAID 

LINE  FUN 


INVOICE_AMOUNT  TERM_TYPE  TER  DATES 
AMOUNT  PAID 


I  [  ]  [12345678]  [23NOV79]  $[99999.99]  [SEM]  [OIDEC  >-05JAN80i 

[ ABCDEFCH ]  [10DEC79]  $[55555.00] 


If  the  user  had  chosen  option  B  from  menu  V3.2  he  would  be  ible  to 
examine  and/or  update  the  points  of  contact  for  each  school  and  >rogra;n. 
This  is  accomplished  using  menu  V3.2.2  just  as  any  other  update  <.  isplay. 

MENU  V3.2.2:  UPDATE  POINTS  OF  CONTACT 


SCHOOL  HEADER  (D3) 
NAME 

LINE  FUN 


PHONE 


.00 RAM 


ADDRESS 


(  1  ( 
[ 

[  1  ( 


1  [ 
]  l 
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EXAMPLE : 


SCHOOL  HEADER 

NAME 


LINE  FUN 


ADDRESS 


PHONE  P  .GRAM 


1  [  )  (DR.  MICKEY  M.  MOUSE  ]  [999-123-456]  [CO  SCI  ] 

[COMPUTER  SCIENCE  DEPT,  UNIV  OF  DISNEY  UORLD,  ORLANDO  FLA  ] 


Option  C  fom’menu  V3.2  the  user  to  update  the  entries  on  t  <_■  cost 
matrix  for  a  particular  school  or  simply  generate  it.  The  f*  Mat  and 
content  of  this  function  and  its  display  have  not  been  decided  ipon  by 
the  user  and  cannot  be  covered  in  detail  here,  './hat  is  know  at  this 
time  is  that  the  matrix  will  need  to  be  able  to  be  specified  for  .  given 
year  and  program.  It  will  contain  a  list  of  the  charges  t!  school 
levies  against  the  Air  Force  under  its  contract  along  with  the  <  >sts  of 
all  the  various  fees,  tuition  rates  and  any  other  cost  related  c'  ,rges. 

The  user  will  be  able  to  specify  the  year  and  program  us  g  menu 
V3.2.3,  and  in  turn  select  the  actual  desired  costs  using  menu  V  .2.3.1. 

MENU  V3.2.3:  UPDATE  AND/OR  CENERATE  COST  MATRIX 


SCHOOL  HEADER  (D3) 

ENTER  THE  DESIRED  YEAR  AND/OR  PROGRAM 
YEAR  [  ] 

PROCRAM  [  ] 


MENU  V3.2.3.1:  SELECT  THE  DESIRED  COST 
SCHOOL  HEADER 

ENTER  THE  DESIRED  COST  [  ] 


A: 

TUITION 

B: 

FEES 

Q: 

QUIT 

The  remainder  of  the  FSS  has  not  been  finalized  by  the  use  For¬ 
mats  and  content  have  yet  to  be  decided.  It  is  anticipated  that  uc  sys¬ 
tem  would  behave  as  described  below. 

The  last  two  options  will  not  have  a  menu  associated  w  n  t hew 
because  these  functions  simply  generate  a  display  or  a  prinio  .  This 
information  will  have  to  be  computed  from  other  data  in  the  dat.  jsc  as 
needed  and  it  is  very  likely  that  these  functions  could  cons  .<.•  large 
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amounts  of  time  during  production.  Therefore,  they  should  be  reduced 
off-line  or  In  a  batch  mode.  This  will  free  the  terminal  for  oi  er  work 
and  provide  the  user  the  ability  to  view  the  report  at  a  later  i  me  and 
at  his  leisure. 

The  associated  displays  should  simply  notify  the  user  that  lie  has 
requested  this  option  and  the  reports  are  being  generated.  Once  umplete 
or  a  batch  job  has  been  spawned,  control  will  return  back  to  ra»  u  V3.2 
and  allow  the  user  to  perform  other  wor.k* 


MENU  V3.2.4:  PRODUCE  COST  FORCASTS 
SCHOOL  HEADER  (D3) 

PRODUCINC  COST  FORCASTS  FOR:  (actual  school  name) 


MENU  V3.2.5:  PRODUCE  CURRENT  COSTS 
SCHOOL  HEADER  (D3) 

PRODUCING  CURRENT  COSTS  FOR:  (actual  school  name)  MENU  V3.2.5: 

PRODUCE  CURRENT  COSTS 


Repriced  WT 
eopy 
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MODULE  DESCRIPTIONS  FOR  THE  AFIT/C1V 
FINANCIAL  SUB  SYSTEM  (FSS)  SOFTWARE 


Further  information  on  any  of  the  menus  or  displays  can 
be  found  in  the  Functional  Description  (FD)  of  the  CFS 
software.  Appendix  IIIF. 

MODULE  1 

**************************************************************** 

* 

*NAME :  CIV  FINANCIAL  SUBSYSTEM 

* 

‘FUNCTION:  This  is  the  main  program  for  the  CFS  and  handles  the 

*  calls  for  the  user. 

* 

‘INPUT:  USERID 
‘OUTPUT:  NONE 

**************************************************************** 

PROCEDURE: 

do  while  FUNCTION  not  -  'QUIT' 
call  CET_FSS_FUNCTION  (FUNCTION) 
if  FUNCTION  -  'STUDENT  PAYMENTS' 

then  call  PROCESS_STUDENT  (FUNCTION) 
else  If  FUNCTION  -  'SCHOOL_PAYMENTS ' 
then  call  PROCESS  SCHOOL  (FUNCTION) 
else  if  FUNCTION  ■  tQUIT'  then  do  nothing 
end  main  loop 


MODULE  2 

**************************************************************** 

* 

‘NAME:  CET_FSS_F  UNCTION 

* 

‘FUNCTION:  This  subroutine  returns  a  single,  valid  function 

*  which  corresponds  to  which  subroutine  the  user  wishe 

*  l<>  enter. 

* 

‘INPUT:  NONE 
‘OUTPUT:  FUNCTION 

*********************** ***************************************** 

PROCEDURE: 

error  *  lb  ;a  binary  value  turned  on  for  loop  control 
do  while  input  not  *  A,  11 ,  (j  ;do  while  input  is  not  valid 
print  display  lines  on  crt  (display  VI) 
error  •  Ob  ;turn  it  off  until  th_  user  makes  an  error 
get  input  line 
if  input  not  "  Q  then  do 

if  input  -  'A'  then  FUNCTION  -  ' STUDENT  PAYMENTS' 
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else  if  input  >*  'B'  then  FUNCTION  -  'SCHOOL  PAYMENTS' 
else  do 

error  *  lb  ;turn  error  indicator  on 
print  error  message  for  invalid  function 
end 
end 

else  FUNCTION  -  ’QUIT’ 
end  main  loop 


MODULE  3 

****************************************************************  * 


*  * 

♦NAME :  PR  OC  E  S  S_S  TUDE  NT  * 

*  x 

♦FUNCTION:  This  subroutine  acts  as  the  driver  for  the  Student  * 

*  Financial  Sub  System  (STFSS)  and  calls  the  functions  * 

*  the  user  requests.  * 

*  k 


♦INPUT:  NONE  * 

♦OUTPUT:  FUNCTION  (indicates  a  request  to  quit)  * 

****************************************************************  * 


PROCEDURE: 

do  while  FUNCTION  not  -  'QUIT' 

call  GE T_S TUDE MT_S SAN  (FUNCTION,  SSAN) 

If  FUNCTION  not  -  ’QUIT’  then  do 
retrieve  data  for  student  header 

display  data  on  CRT  in  the  D1  format,  as  a  protected  fie 
call  SELECT_STUDENT_FUNCTION  (FUNCTION) 
if  FUNCTION  not  -  'QUIT'  then  do 

if  FUNCTION  -  'INVOICES'  then  call  UPDATE_INV01CES  (FI'  'iTON, 
else  if  FUNCTION  -  ’COSTS' 

then  call  QUERY_PROG_COSTS  (FUNCTION,  SSAN) 

else  if  FUNCTION  ■>  'STUDENT'  do  nothing  ;get  •  other 

end 

end 

end  main  loop 


55..  ) 

55.. .1 
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MODULE  4 

****************************************************************  -  * 

*  * 

‘NAME:  PROCESS_SCHOOL  * 

*  * 

‘FUNCTION:  This  subroutine  acts  as  the  driver  for  the  School  * 

*  Financial  Sub  System  (SFSS)  and  call®  the  functions  * 


*  the  user  requests.  * 

*  * 

‘INPUT:  NONE  * 

‘OUTPUT:  FUNCTION 


*  ***************************************************************  .  * 

PROCEDURE: 

do  while  FUNCTION  not  -  'QUIT' 

call  GET  SCHOOL  (FUNCTION,  SCHOOL  NAME) 
if  SCHOOrjJAME  not  -  'QUIT'  then  Ho 

retrieve  school  header  data  ;screen  display  D3 
display  school  header  data  on  crt 
call  SELECT_SCliOOL  FUNCTION  (FUNCTION)  ;raenu  V3.2 
if  FUNCTION  not  -  ^QUIT '  then  do 
if  FUNCTION  -  'INVOICES  &  VOUCHERS' 

then  call  UPDATE_1NVOICES/VOUCHERS  (FUNCTION,  SCHOOL  AME) 
else  if  FUNCTION  -  'POC' 

then  call  UPDATE_POCS  (FUNCTION,  SCHOOL_NAME) 
else  if  FUNCTION  -  'MATRIX' 

then  call  UPDATE_COST_MATRIX  (FUNCTION,  SCHOOL_NAME) 
else  if  FUNCTION  *  'FORCAST' 

then  call  PRODUCE_COST_FORCASTS  (FUNCTION,  SCHOOL_NA  ) 
else  call  CURRENT_COSTS  (FUNCTION,  SCHOOL_NAME) 
end  if  block 
else  FUNCTION  -  'QUIT' 
end  main  loop 


MODULE  5 

******************************************* *********************  * 

*  * 

*  NAME :  CET_S  TU  DE  NT_S  SAN  * 

*  * 

‘FUNCTION:  This  subroutine  returns  a  unique  SSAN  for  a  student  * 

‘  using  menu  V2.  The  user  may  quit  by  entering  a  * 

*  'Q '  in  SSAN.  * 

*  * 

‘INPUT:  NONE  * 

‘OUTPUT:  SSAN,  FUNCTION  * 

****************************************************************  •  * 

PROCEDURE: 

error  ■  lb  ;a  binary  value  turned  on  for  loop  control 
do  while  FUNCTION  not  -  'QUIT'  &  error 

error  ■  Ob  ;turn  it  off  until  the  user  nakes  an  error 
display  menu  V2 
get  input  line 
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check  input  for  all  numeric 
if  input  not  numeric  then  do 
error  ■  lb 

print  message  for  incorrect  function 
if  input  -  'Q'  then  FUNCTION  -  ‘QUIT  * 
end 

end  main  loop 


MODULE  6 

****************************** **********************************  * 


*  * 

‘NAME :  SELECT  STUDENT  FUNCTION  * 

*  * 

‘FUNCTION:  This  subroutine  gets  the  users  function  from  Menu  V2 . . * 

*  and  returns  it  to  the  calling  program.  * 

*  * 

* INPUT:  NONE  * 

‘OUTPUT:  FUNCTION  * 


a***************************************************************  ;* 

PROCEDURE: 

error  -  lb  ;a  binary  value  turned  on  for  loop  control 
do  while  FUNCTION  not  -  'QUIT'  &  error 

error  ■  Ob  ;turn  it  off  until  the  user  makes  an  error 

display  menu  V2.1 

get  input  line 

if  input  not  ■  'Q'  then  do 

if  input  -  'A'  then  FUNCTION  -  'INVOICES’ 
else  if  input  -  'B'  then  FUNCTION  -  'COSTS' 
else  if  input  -  'C'  then  FUNCTION  -  'STUDENT' 
else  do 

error  -  lb  ;flag  the  error 
print  an  error  message  to  the  user 
end 
end 

else  FUNCTION  -  'QUIT' 
end  main  loop 
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MODULE  7 

A**************************************************************#: 


•NAME :  UPDATE_INVOICES 

* 

•FUNCTION:  This  subroutine  allows  the  user  to  update  the  invoic. 

*  charged  to  a  particular  student.  Each  time  a  comman 

*  (function)  is  issued,  the  data  is  changed  in  the 

*  database  the  data  is  retrieved  again  and  the  screen 

*  is  refreshed  with  the  latest  copy  of  the  invoices  as 

*  stored  in  the  database.  This  subroutine  uses  Menu 

*  V2.1.1  and  display  D3. 


•INPUT: 
•OUTPUT : 


STUDENT_SSAN 

FUNCTION 


*  **  A  **********  it  irk  **  *****  kirk  It  -kit  it  k  ****  ****  ****  kirk  k  k  kkk  k  *  *  A**  A  **  kk  k  *  it 

PROCEDURE: 

do  while  FUNCTION  not  -  'QUIT  &  error 

error  •  Ob  ;error  is  a  binary  value,  turn  it  off 
retrieve  student  invoices  data 

display  student  invoice  data  in  menu  V2.1.1  format 
call  GET_INVOICE_LINE  (input  line) 

;ifun  is  the  second  field  in  the  input  line 

;a  check  must  be  made  to  insure  the  line  number  was  not  •  hanged 
by  the  user 

if  ifun  not  *  ' Q *  &  line_no  not  changed  then  do 

if  ifun  ■  *+'  or  '  then  move  display  lines  up  or  down  n  screen 
else  if  ifun  -  'A'  the  call  ADD_INVOICE_TUPLE  (data  fiel  s) 

else  if  ifun  -  'C'  then  call  CHANCE_INVOICE_TUPLE  (data  ields) 

else  if  ifun  -  'D'  the  call  DELETE_INVOICE_TUPLE  (data  l  elds) 

else  do 

error  -  lb  ;turn  error  on 
print  error  message  for  invalid  function 
end 

else  FUNCTION  ■  'QUIT'  ;quit  this  operation 
end  main  loop 

NOTES:  See  the  final  section  for  an  explanation  of  the  A,  C  anc  J  functio 
an  modules. 
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MODULE  8 

******************************** ********************************/  * 

*  * 

‘NAME:  GET_INVOICE_LINE  * 

*  •* 

‘FUNCTION:  This  subroutine  gets  the  data  line  from  Menu  V2.1.1  * 

*  and  checks  the  values  of  the  fields  for  validity.  * 

*  It  will  not  return  to  the  calling  program  until  all  * 

*  fields  are  correct  or  a  *  Q  *.  has  been  entered  as 

*  function. 

*  * 

‘INPUT:  NONE  * 

‘OUTPUT:  one  data  line  with  fields  separated  by  a  delimiter  * 

***************************************““““““““““““*'-'  * 

PROCEDURE: 

error  ■  lb  ;a  binary  value  turned  on  for  loop  control 
do  while  error 

error  ■  Ob  ;turn  it  off  until  the  user  makes  an  error 
get  line 

if  ifun  not  »  'q'  then  do  ;ifun  is  the  second  field  on  th.  input  lin 
validate  all  field  values  for  format  and  content 
query  database  to  validate  the  AMOUNT_TYPE  ;see  if  it  i?  there 
if  any  field  fails  then  do 
error  ■  lb  ;flag  the  error 
print  an  appropriate  error  message 
end 

end  main  loop 


MODULE  9 

****************************  ******  *****“““>'  *x  * 

*  * 

‘NAME:  QUERY_PKOC_COSTS  * 

*  K 
‘FUNCTION:  This  subroutine  allows  the  user  to  query  the  various  * 

*  costs  incurred  by  a  student  in  a  particular  program.  K 

*  It  uses  menu  V2.1.2  and  display  D2.  x 

*  * 

‘INPUT:  STUDENT_SSAN  * 

‘OUTPUT:  FUNCTION  * 

A***************************************************************’  * 

PROCEDURE: 

do  while  FUNCTION  not  -  ’QUIT' 
retrieve  student  cost  data 
call  CET_COST_TYPE  (COST_TYPE,  FUNCTION) 

if  COST_TYPE  -  'TUITION'  then  retrieve  tuition  data  (for  t»  SSAN) 
else  if  COST_TYPE  -  'LAB '  then  retrieve  lab  fee  data 
else  if  COST_TYPE  -  'BOOKS'  then  retrieve  book  data 

else  if  FUNCTION  not  -  'QUIT'  then  display  data  in  the  fori  .t  for  D2 
end  main  loop 
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NOTES:  This  function  could  not  be  fully  defined  by  the  user  at  :  is  time. 


MODULE  10 

**************************************************************** ;  .  * 

*  A 

‘NAME:  GE  T_C0ST_T  Y  PE  * 

*  * 

‘FUNCTION:  This  subroutine  allows  the  user  to  select  the  type  o.  * 

*  costs'he  wishes  to  update.  * 

*  A 

‘INPUT:  NONE 

‘OUTPUT:  COST  TYPE,  FUNCTION  * 


*****  ***********************************************************  f  X 

PROCEDURE: 

error  •  lb  ;a  binary  value  turned  on  for  loop  control 
do  while  error 

error  ■  Ob  ;turn  it  off  until  the  user  makes  an  error 
display  menu  V2.1.2 
get  line 

if  input  not  ■  'Q'  then  do 

if  input  -  'A'  then  COSTJYPE  -  'TUITION' 
else  if  input  -  'B'  the  C0ST_TYPE  -  'LAB' 
else  if  input  -  'C'  then  C0ST_TYPE  *  "WOKS ' 
end 

else  do 

error  *  lb  ;flag  the  error  for  the  loop 
print  the  appropriate  error  message 
end 

else  if  Input  -  Q  then  FUNCTION  -  ’QUIT' 
end  main  loop 


MODULE  11 

****************************************************************  * 
*  * 

‘NAME:  CET  SCHOOL  * 

*  * 

‘FUNCTION:  This  subroutine  returns  a  single,  valid  name  of  the  * 
‘  school  the  user  wishes  to  query/update .  If  the  nami  * 

*  is  unknown,  the  user  may  request  a  list  of  schools  ii  * 

*  a  particular  state  and  choose  one  from  the  list.  * 

*  A 

‘INPUT:  NONE 

‘OUTPUT:  SCH00L_NAMF. ,  FUNCTIONON 

****************************************************************-  x 

PROCEDURE: 

error  ■  ib  ;a  binary  value  turned  on  for  loop  control 
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do  while  FUNCTION  not  -  'QUIT1  &  error 

error  ■  Ob  ;turn  it  off  until  the  user  makes  an  error 
call  CET_SCHOOL_NAME  (SCHOOL_NAME,  STATE,  FUNCTION) 
check  the  school  name  in  the  data  base 
if  not  valid  or  does  not  exist  then  do 
error  -  lb  ;flag  the  error  for  the  loop 
print  an  error  message  for  an  unknown  school 
end 

else  if  FUNCTION  not  -  'QUIT'  then 

if  SCIiOOL_NAME  -  blanks  &  STATE  not  =  blanks 

then  call  <JENERATE_SC1100L_LIST  (STATE,  SCHOOL_NAME,  FU.  TIONON) 
else  if  SCHOOL_NAME  &  STATE  -  blanks  then  do 
error  ■  'lb  ;flag  the  error  for  the  loop 
print  an  error  message  for  invalid  function 
end 

end  main  loop 


MODULE  12 

*******************************************  *************  *******  * 

*  x 


♦NAME:  CET_SCHOOL_NAME 

* 


♦FUNCTION: 


0** 


* 

* 

* 


This  subroutine  displays  menu  V3  and  returns  a  singl> 
school  name  by  allowing  the  user  to  enter  it  directl> 
or  request  a  list  of  schools  in  a  state. 


A 

* 

k 

k 

>ic 

k 


♦INPUT:  NONE  * 

♦OUTPUT:  SC!IOOL_NAME,  FUNCTIONON 

*****************************************************************  * 


PROCEDURE: 

error  *  lo  ;a  binary  value  turned  on  for  loop  control 
do  while  FUNCTION  not  -  'QUIT'  &  error 

error  ■  Ob  ;turn  it  off  until  the  user  makes  an  error 
display  menu  V3 
get  input 

if  ifun  -  'Q'  then  FUNCTION  -  'QUIT'  ;ifun  is  the  third  fi  Id 
else  do 


if  SCHOOL_NAME  ■  blanks  &  STATE  not  *  blanks  ;user  want:  i  list 
then  validate  state  ;uses  the  standard  2  letter  abbrev 
if  STATE  is  invalid  then  do 

error  ■  lb  ;flag  the  error  for  the  loop 
print  an  error  message  for  state  not  found 
end 

end  main  loop 
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c 


h 

s  ov 


l-'. 

I 


I 

I 

I 


(i 


MODULE  13 

****************************************************************.  * 

*  * 

*NAME :  CENERATE_SCHOOL_LIST 

*  * 

‘FUNCTION:  This  subroutine  takes  a  2  letter  state  abbreviation  * 

*  and  retrieves  all  the  AFIT/CI  schools  which  are  ther,  ,* 

*  and  allows  the  user  to  choose  one  from  menu  V3.1.  * 

*  * 

* INPUT:  STATE  * 

‘OUTPUT:  SCHOOL_NAME,  FUNCTION  * 

****************************************************************  K 

PROCEDURE: 

retrieve  schools  for  the  state 
display  data  in  the  format  of  V3.1 

error  ■  lb  ;a  binary  value  turned  on  for  loop  control 
do  while  FUNCTION  not  -  'QUIT'  (.  error 

error  ■  Ob  ;turn  it  off  until  the  user  makes  an  error 
get  input  line 

check  line  number  for  correctness 
if  too  large  or  garbage  then  do 

error  -  lb  ;flag  the  error  for  the  loop 
print  a  nasty  message  to  not  change  line  numbers 
end 

else  if  line  number  points  to  quit  (uses  an  array  to  store  .'alues) 
then  FUNCTIONON  -  'QUIT* 

else  SCHOOL_NAME  *  data_array  (iine_no)  .school_narae 
end  main  loop 


MODULE  1 A 

*********************************** ****** ***********************  A* 


* 


* 


‘NAME:  SELECT  SCHOOL  FUNCTION  * 

*  * 

‘FUNCTION:  This  subroutine  allows  the  user  to  select  the  functi  i* 

*  he  wishes  to  perform  for  a  specific  school  from  menu  * 

*  V3.2.  * 

*  * 


‘INPUT:  NONE  * 

‘OUTPUT:  FUNCTION  * 

****************************************************************  ** 


PROCEDURE: 

error  ■  lb  ;a  binary  value  turned  on  for  loop  control 
do  w'lle  FUNCTION  not  -  'gUIT'  &  error 

error  -  Ob  ;turn  it  off  until  the  user  makes  an  error 
display  menu  V3.2 
get  Input 

if  input  not  ■  'Q*  then  do 

if  input  -  'A'  then  FUNCTION  -  ' INVOICES/VOUCIIERS ' 
else  if  input  -  'li'  then  FUNCTION  -  'POC' 
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else  If  input  -  'C'  then  FUNCTION  *  'MATRIX' 

else  if  input  -  'D'  then  FUNCTION  -  'FORCAST' 

else  if  input  -  'E*  then  FUNCTIONON  -  'ONGOINC' 

else  do 

error  ■  lb  ;flag  the  error  for  the  loop 
print  and  error  message  for  invalid  input 
end 

else  FUNCTION  -  ’QUIT’ 
end  main  loop 


MODULE  15 

**************************************************************** v  A 
*  * 

•NAME:  UPDATE_INVO ICES /VOUCHERS  * 

*  * 

•FUNCTION:  This  subroutine  is  the  main  driver  and  allows  the  us>  * 

*  to  update/view  the  invoices  and  vouchers  which  belon;  * 

*  to  a  particular  school.  It  uses  menu  V3.2.1.  * 

*  * 

•INPUT:  SCHOOL_NAME  * 

•OUTPUT :  FUNCTION  * 

****************************************************************>  X 

PROCEDURE: 

error  *  lb  ;a  binary  value  turned  on  for  loop  control 
do  while  FUNCTION  not  -  'QUIT*  &  error 

error  -  Ob  ;turn  it  off  until  the  user  makes  an  error 
retrieve  vouchers  and  invoices  data  for  the  school 
display  the  voucher  and  invoice  data  in  the  format  for  V  3.  .1 
get  input  line 

;ifun  is  the  second  field  on  the  input  line 
if  ifun  not  ■  *Q '  then  do 
check  all  the  input  fields 

check  the  database  for  the  validity  of  the  term_type 
if  errors  then  do 

error  *  lb  ;flag  the  error  for  the  loop 
print  appropriate  error  message 
end 

if  ifun  ■  '+'  or  then  move  display  lines  up  or  down  i  screen 

else  if  ifun  -  'A'  then  cal’.  ADD_INVOICE_TUPLE  (input  dat  .) 

else  if  ifun  -  'C'  then  call  CHANCE_1NV0ICE_TUPLE  (input  ata) 

else  if  ifun  -  'D'  then  call  DE LE TE_I N VO IC E_T U PL E  (input  ata) 

end 

else  if  line  numbers  changed  then  do 

error  ■  lb  ;flag  the  error  for  the  loop 
print  nasty  message  not  to  change  the  line  numbers 
end 

else  if  ifun  -  'Q'  then  FUNCTION  -  'QUIT' 
end  main  loop 

NOTES:  See  the  final  section  for  an  explanation  of  the  A,  C  and  •  functio 
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■.  I*. "  1  *  ' 


MODULE  16 

*************************************************************** *1  A 

*  A 

♦NAME:  UPDATE_POCS  * 

*  A 

♦FUNCTION:  This  subroutine  Is  the  driver  for  updating  the  * 

*  Points  of  Contact  for  a  given  school.  It  uses  menu  * 

*  V3.2.2. 

*  * 

♦INPUT:  SC1100L_NAME 
♦OUTPUT:  FUNCTION 

************************************************ ****************;  a 

PROCEDURE: 

error  m  lb  ;a  binary  value  turned  on  for  loop  control 
do  while  FUNCTION  not  -  'QUIT*  &  error 

error  ■  Ob  ;turn  it  off  until  the  user  makes  an  error 
retrieve  POC  data  for  the  school 
display  POC  data  in  the  format  of  V3.2.2 
get  input  line 

;  ifun  is  the  second  field  on  the  input  line 
if  ifun  not  ■  'Q'  &  line  number  not  changed  then  do 
check  all  input  fields  for  validity 
if  errors  then  do 

error  ■  lb  ;flag  th '  error  for  the  loop 
print  the  appropriate  error  message 
end 

else  do 

if  ifun  ■  •+’  or  then  move  display  lines  up  or  dow:  on  screen 

else  if  ifun  ■  'A'  then  call  ADD_POC_TUPLF.  (input  data) 

else  if  ifun  -  'D'  then  call  DELETE_POC_TUPLE  (input  d.  a) 

else  if  ifun  ■  *C'  then  call  CHANCE_POC_TUPLE  (input  d.  i) 

else  do 

error  ■  lb  ;flag  the  error  for  the  loop 
print  error  message  for  invalid  function 
end 

else  if  line  number  changed  then  do 

error  ■  lb  ;flag  the  error  for  the  loop 
print  nasty  message  to  not  change  line  numbers 
end 

else  if  ifun  -  'Q'  then  FUNCTION  -  'QUIT' 
end  main  loop 

NOTES:  See  the  final  section  for  an  explanation  of  the  A,  C  and  functioi. 

and  modules. 


Reproduced  from 
jest  available  copy. 
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MODULE  17 

kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk  .  x 

*  A 

‘NAME:  UPDATE_COST_MATRIX 

k  k 

‘FUNCTION:  This  subroutine  acts  as  the  main  driver  which  will  * 

*  allow  the  user  to  update  the  cost  matrix  using  menu  * 


*  V3.2.3.1. 

*  X 

‘INPUT:  SCHOOL_NAME  * 

‘OUTPUT:  FUNCTION 


kkkkkk kkkkkkkkkkkkkkkkkk kk k kk kkkkk kkk kkk kkkkkkkkkkk k k kkkkkkkkkkk  y  « 

PROCEDURE: 

error  *  lb  ;a  binary  value  turned  on  for  loop  control 
do  while  FUNCTION  not  -  'QUIT'  4  error 

error  ■  Ob  ;turn  it  off  until  the  user  makes  an  error 
call  C.ET_YE AR_AN D_P ROCRAM  (YEAR,  PROGRAM,  FUNCTION) 
display  menu  V  3. 2. 3.1 
get  input 

check  input  for  validity 
if  not  valid  then  do 

error  *  lb  ;flag  the  error  for  the  loop 
print  and  error  message  for  invalid  function 
end 

if  not  error  &  input  not  ■  'Q'  then  do 
if  input  ■  'A'  then 

call  UPDATE_TUIT IONJMATRIX  ( S CHOOL_N AME ,  YEAR,  PROCRAM  -UNCTION 
else  call  UPDATE_FEE_MATRIX  (SCUOOL_NAME ,  YEAR,  PROGRAM,  UNCTIONO 
end 

end  main  loop 


MODULE  18 

*********** ******************************************* ********** 

* 

‘NAME:  FORCAST_COSTS 

* 

‘FUNCTION:  This  subroutine  allows  the  user  to  update  the  cost  ft 

‘  casting  information.  It  is  the  main  driver  for  this 

*  function  and  uses  me  iu  V3.2.4. 

* 

‘INPUT: 

‘OUTPUT: 

**************************************************************** 

PROCEDURE: 

THERE  IS  INSUFFICIENT  DATA  AT  THIS  TIME  TO  DESCRIBE  THE  PROCEDUR  OF  TiilS 

MODULE . 


.  * 

* 

k 

A 

k 

k 

k 

k 

k 
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MODULE  19 

ft***************************************************************:  ,? 

*  .< 

♦NAME:  CURRENT_COSTS  * 

*  X 

♦FUNCTION:  This  subroutine  allows  the  user  to  update  or  examine  * 

*  the  current  costs  incurred  for  a  given  school.  It  A 

*  uses  menu  V3.2.5.  * 

*  A 

* INPUT :  * 

♦OUTPUT : 

****************************************************************:  * 

PROCEDURE: 


THERE  IS  INSUFFICIENT  DATA  AT  THIS  TIME  TO  DELCRIBE  THE  PROCEDUK!  OF  THIS 
MODULE . 


MODULE  20 

******************** * ******* * ******* * ******* * *** * ************** * ,  * 


♦NAME :  CET_YEAR_AND_PROCRAM  * 

*  * 

♦FUNCTION:  This  subroutine  gets  a  year  and/or  a  program  using  * 

♦  menu  3.2.2.  * 

*  * 

♦INPUT:  NONE  * 

♦OUTPUT:  YEAR,  PROGRAM,  FUNCTION  * 


****************************************************************>  .  * 

PROCEDURE: 

error  ■  lb  ;a  binary  value  turned  on  for  loop  control 
do  while  input  not  "  'Q'  &  error 

error  ■  Ob  ;turn  it  off  until  the  user  makes  an  error 
display  menu  3.2.2 
get  line 

check  input  fields 
if  errors  then  do 

error  *  lb  ;fl««g  the  error  for  the  loop 
print  an  error  message  for  invalid  input 
end 

end  main  loop 


4 


4 
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MODULE  21 

It  A  ****************  *****************  A  A*  AAA  ************  *******  ****;  * 


A  A 

‘NAME:  UPDATE_TUITION_MATRIX  * 

*  * 

‘FUNCTION:  This  subroutine  acts  as  the  driver  which  will  allow  * 

*  the  user  to  update/examine  the  tuition  cost  matrix.  * 

*  * 

* INPUT:  YEAR,  SCHOOL  NAME,  PROCRAM  * 

‘OUTPUT:  FUNCTION  “  * 


****************************************************************  * 

PROCEDURE: 

error  -  lb  ;£rror  is  a  binary  value,  set  if  for  the  loop 
do  while  ifun  not  «  'Q'  &  error 
error  -  Ob  ;turn  it  off 
retrieve  tuition  matrix  data 

display  tuition  matrix  ; format  has  not  been  finalized  by  t  ,o  user 
get  input  line 

;ifun  is  the  second  field  on  the  input  line 
;  line  numbers  must  be  checked 

if  ifun  not  ■  ' Q *  &  line  numbers  not  changed  then  do 
check  all  Inputs 
if  errors  then  do 

error  ■  lb  jflag  the  error  for  the  Loop 
print  the  appropriate  error  message 
end 

if  ifun  ■  '+'  or  Chen  move  display  lines  up  or  down  <  screen 
else  if  ifun  -  'A'  then  call  ADD_TUITION_TUPLE  (input  dat  ,) 

else  if  ifun  -  'C'  then  call  CHANCE_TUITION_TUPLE  (input  ita) 

else  if  ifun  -  'D'  then  call  DELETE_TUITION_TUPLE  (input  ati) 

end 

end  main  loop 

NOTES:  See  the  final  section  for  an  explanation  of  the  A,  C  and  i  function  ■ 
and  modules. 


MODULE  22 

********************************  ********************************  ■  * 

*  * 

*NAME:  U  PDATE_FFE_MATR I X  * 

*  * 

‘FUNCTION:  This  subroutine  is  the  driver  which  allows  the  user  i  * 

*  updnte/view  the  various  fees  charged  by  a  school.  * 

* 

‘INPUT:  YEAR,  PROCRAM,  SC1I00L_NAME 

‘OUTPUT:  FUNCTION  * 

****************************************************************  * 

PROCEDURE: 

error  ■  lb  ;error  is  a  binary  value,  set  it  for  the  loop 

do  while  ifun  not  ■  * Q *  &  error  ;ifun  is  the  seconu  field  o.  the  input  line 
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error  ■  Ob  ;turn  It  off 
retrieve  fee  matrix  data 

display  fee  matrix  ;format  is  not  yet  finalized  by  the  us. 
get  input 

check  all  input  for  validity 
if  errors  then  do 

error  ■  lb  ;flag  the  error  for  the  loop 
print  appropriate  error  message 
end 

if  ifun  not  ■  'Q'  &  line  numbers 'not  changed  then  do 

if  ifun  ■  or  then  move  display  lines  up  or  down  .  .  screen 
else  if  ifun  *  'A'  then  call  ADD_FEF._TUPLE  (input  data) 

else  if  ifun  -  *C'  then  call  CHANCE_FEE_TUPLE  (input  dat. 

else  if  ifun  -  'D'  then  call  DELETE_FEE_TUPLE  (input  dat. 

else  if  ifun  -  'Q'  then  FUNCTION  -  'QUIT' 

end 

end  main  loop 

MOTES:  Sec  the  final  section  for  an  explanation  of  the  A,  C  and  functions 
and  modules. 
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DESCRIPTIONS  OF  THE 
ADD,  CHANCE  AMD  DELETE  MODULES 

in  +5 

For  of  these  modules,  found  In  the  update  routines, 
each  has  the  same  basic  procedure  and  arguments.  The  only 
difference  between  them  is  the  actual  database  selection 
expressions,  required  to  accurately  .  identify  the  tuples 
(data)  in  question. 

The  'ADD'  modules  will  only  take  the  data  input  by  the 
user  and  add  it’to  a  relation,  or  relations  depending  upon 
what  it  was  written  for.  Likewise  the  "DELETE'  modules  will 
only  remove  data  specified  by  the  user.  In  order  to  keep 
things  simple,  straightforward  and  help  the  readability  of 
the  code,  a  'CHANCE'  module  will  call  the  'DELETE'  then  the 
'ADD'  modules  respectively. 

The  above  method  of  constructing  the  'CHANGE'  module  is 
also  preferred  because  most  DBMSs  will  not  allow  a  key  field 
to  be  modified  using  a  "change"  or  "modify"  command.  There¬ 
fore  the  only  way  to  modify  a  key  field  is  to  first  delete 
it  then  add  the  new  one.  Depending  upon  the  actual  DBMS 
Implemented  at  AFIT,  this  may  or  may  not  have  to  be  done 
this  way. 
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NEW  AND  MODIFIED  RELATIONS,  NEW  ATTRIBUTES, 
AND  FUNCTIONAL  DEPENDENCIES  FOR  AFIT/CIR/M 


NEW  RELATIONS 


1,  CI_SUSPENSE_TYPE: 

Type*,  Description 
(See  note  1) 

(Describes  the  various  types  of  Cl  suspenses.) 

2.  CI_SUSPENSE: 

SSAN*,  S_Date*,  Type*,  Description* 

(Contains  data  about  a  given  suspense  for  a  particula  student.) 


3.  CI_TERM_TYPE : 

Term*,  Description 

(Describes  the  various  types  of  civilian  academic  ins  .tution  ti eras.) 


4.  CI_TERM : 

SSAN*,  Term*,  Start_Date*,  Stop_Date 

(Contains  data  about  a  particular  term  for  a  given  st  ent.) 


5.  CI_ED_PLAN: 

SSAN*,  Course_ID,  Course_Dept,  Course_No*,  Course_Tit  , 
Term_No*,  Credits,  Start_Date* 

(Contains  data  about  a  particular  Cl  student's  Ed  Pla  .) 


6.  CIJGRADES: 

SSAN*,  CourseJNo*,  Term_No*,  Grade,  Start_Date* 

(Contains  data  about  the  grade  a  particular  Cl  studen  ^ot  for 
a  given  course.) 

7.  CI_Student_Manager : 

SSAN*,  PM 

(Defines  who  a  given  Cl  student's  program  manager  (PM  is.) 
MODIFIED  RELATIONS 


I.  CI_DATA: 

Add  Advisor,  Grad  Date,  CRE_Verbal,  CRE_Quant  as  attr  utes 
(See  note  2) 


Reproduced  from 
best  available  copy. 


Appendix  1 1  111 


PACE  i 


NEW  ATTRIBUTE  DESCRIPTIONS 


ATTRIBUTE 

xxxxxxxxx 

RELATIONS 

xxxxxxxxx 

DESCRIPTION 

xxxxxxxxxxx 

EXAMPLE 

xxxxxxx 

SIZE 

xxxx 

1.  Course_ 

Dept 

5 

(See  note 

3) 

Dept,  offering 
a  course 

EE 

2 

2.  Course 

ID 

5 

Course  ident¬ 
ifier 

? 

(See  note  4) 

TBD 

3.  Course 

No 

5*, 6* 

(See  note 

5) 

Course  number 

7.93 

4 

4.  Course 

Title 

5 

— 

DATABASE  1 

JO 

5.  Start_ 

Date 

4*, 5*, 6* 

Date  a  term 
started  or 
will  start 

090182 

6.  PM 

7 

Program 

manager 

Also  is  the 
last  2  char 
of  the  Cl 
users  ID 

RQ 

> 

7.  Stop_ 

Date 

4 

Date  a  term 
stopped  or 
will  stop 

121582 

b 

8.  S_Date 

2* 

Suspense  l>ate 

121782 

6 

9.  Type 

l*,2* 

Code  for  type 
of  suspense 

? 

TBD 

10.  Term 

3*, 4* 

Code  for  type 

SI  (Summer  1 

Q  (Quarter) 

2 

11.  Term  No 

5*. 6* 

Number  of  a 

particular 

term 

1 

1 

[r*protfucad  from 

— *»*  »viUhU  ,-rv 
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FUNCTIONAL  DEPENDENCIES 


RELATION  FUNCTION  DEPENDENCIES  IMPORTANT  AS  JMPTIONS 

XXXXXXXX  XXXXXXXXXXXXXXXXXXXXX  XXXXXXXXXXXX  vXXXXXXX 

1  l->2,  2->l  (See  notes  6  &  7) 

2  1234->1234 

3  l->2,  2->l 

4  123->4 

5  1468->2357 


6  1235->4  (See  note  8) 

7  l->2 


NOTES 

1.  A  starred  attribute  Indicates  that  this  attribute  is  a  key  o  part  of 
a  key  for  the  relation  that  it  is  starred  in.  2.  CI_Data  is  con¬ 
sidered  a  modified  relation  because  it  was  defined  prior 

to  the  in-depth  analysis  of  AFIT/CI's  needs.  Also,  the  modi  ied  CI_ 
Data  is  still  in  Third  Normal  Form.  3.  A  number  in  the  iLATIONS 
column  refers  to  the  relation  numbers  in 

the  NEW  RELATIONS  section.  4.  A  "?“  and  a  "TBD"  means  that  insuffi¬ 
cient  data  was  available  at  the 

at  the  time  this  appendix  was  written  and  that  this  lnformat  m  needs 
to  be  developed.  5.  A  starred  relation  number  has  the  same  meaning 
as  note  1.  6.  X->Y  means  the  set  of  attributes  X  functional  y  deter¬ 

mines  the  set 

of  attributes  Y,  e.g.  l->2  means  attribute  l  functionally  dc  •mines 
attribute  2.  7.  Attribute  numbers  used  in  describing  1  ctional 

dependencies  are  based 

on  the  ordinal  position  of  the  attribute  within  the  given  re  itlon  in 
the  NEW  RELATIONS  section.  For  example,  l->2  means  that  the  irst 
attribute  in  the  given  relation  functionally  determines  the  cond 
attribute.  8.  All  new  relations  are  in  Third  Normal  Form,  ised  on 
these  FD's,  and 

available  information. 


Type  is  uniq 

Term  is  uniq 

Course  No  is  unique 
for  a  given  .udent 
at  a  partlcu  ir  school 
Course_Title  is  not 
necessarily  nique 
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NEW  OR  MODIFIED  RELATIONS  FOR  AFIT/C1V 


1.  CIV_FEES: 

(FE£_CODE*,  TYPE,  DESCRIPTION,  EEIC_CODE.> 

This  relation  contains  a  list  of  «11  of  the  various  fees  f 
AFIT  can  be  charged.  FEEjCODE  is  a  unique  code  and  TYPE  i 
sification  or  category  to"  which  the  fee  belongs  (e.g. 
specific  medical  fees  could  all  be  classified  as  medfees). 


2.  INST_PAYMENTS: 

(LOCATION_CODE*,  INVOICE_NO*,  DATE_REC* ,  INVOICE_AMT,  l 
VOUCHER  AMT,  VOUCHER  NO,  TERM  ST  DATE,  TERM  END  DATE) 


This  relation  is  the  place  where  all  the  school  transact 
kept.  PMTJCODE  is  the  sane  as  FEE_CODE  and  TUITIONJTYPE 
payment  may  be  made  for  several  kinds  of  costs. 


3.  INSTjCOSTS: 

( LOCAT ION_CODE * ,  TUITIONJTYPE*,  TUITION_PATE) 

This  relation  is  a  list  of  the  various  tuition  rates  which 
may  charge.  TUITION_TYPE  is  a  code  and  a  full  descript 
relation  #3  below.  Examples  of  these  types  are:  undergrad, 
medical . 


4.  INSTjCHARGES: 

(LOCATION  CODE*,  PROCRAM*,  RC/CCC,  FEE  CODE*,  CHARCE) 


This  relation  is  a  list,  by  program,  of  the  charges 
wlll/may  levy  against  the  Air  Force  for  AFIT.  This  essenti 
rate  schedule. 


5.  TUITIONS: 

(TUITIONJTYPE*,  DESCRIPTION) 

This  relation  is  a  list  of  the  TUITION  TYPES  and  their  desr 


6.  SCHOOL/ EWI_DATA: 

(LOCATION  CODE*,  SERVICING  AFO,  ESA_NO,  SCUOOLJTYPE , 

term_type7 

The  contents  and  purpose  of  this  relation  remain  unchang 
fields,  ESA  NO  and  STATE  have  been  added. 


which 
.i  clas- 
several 


:■  CODE*, 


jits  are 
jcause  a 


school 
in  is  in 
;rad  and 


school 
i ly  is  a 


i  ptions . 


STATE, 


Two 
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7.  CI_DATA:  (MODIFIED) 

( . . . . PROCR AM_MCR ,  FUNDI NC_TY PE ) 

The  above  Cwo  attributes  should  be  added  to  the  CI_DATA 
already  defined. 


8.  FUNDINC_TYPES: 

( FUNDINC_TYPE* ,  DESCRIPTION)  ; 

This  relation  Is  a  list  of  the  various  funding  types  or  sou 
AFIT  sponsored  education.  Exanples  are:  funded  legal,... 


9.  Cl  STUDENT_PAYMENTS: 

Tssan*,  START_DATE,  PMT_CODE*,  VOUCHER_AMT,  AMT_K 
DATE_POSTED,  ENDJDATE,  V0UC11ER_N0*,  REM/‘>Ku) 

This  relation  Is  the  place  where  all  the  payments  made  to  a 
are  kept.  The  vouchers  here  should  be  cross  refet 
V0UCHER_N0  to  the  INST_PAYM£NTS  relation.  The  attribute  PM 
the  same  as  FEEjCODE  and  TUITION_TYPE  and  Is  used  the 
relation  t 2. 


10.  ACADJTERMS: 

(TERM  TYPE*,  DESCRIPTION) 


This  relation  Is  a  list  of  the  various  type  of  terms  which 
must  deal  with  (e.g.  qtr,  sem,  summer  sessions  and  trimeste 


11.  SCHOOL_TYPES: 

(SCHOOLTYPE*,  DESCRIPTION) 

This  relation  is  a  list  of  the  various  types  of  schoo 

AFIT/CIV  must  deal  with  (e.g.  state,  private). 

FUNCTIONAL  DEPENDENCIES: 

Based  upon  available  data  and  knowledge,  the  above  relation 
third  normal  form.  Each  set  of  key  attributes  (ones  which  a 
with  an  '*')  wholly  determines  (l.e.  no  subset)  all  of  the  ottu- 
butes. 

ATTRIBUTE  DESCRIPTIONS: 

Insufficient  data  was  available  to  provide  a  detailed  list 
bute  descriptions.  Several  meetings  were  held  with  AF1T/CI  per 
clearly  identify  the  remaining  data  needs,  but  the  amount  was 
large  and  some  very  important  elements  were  not  clear  or 
sistently  enough  to  make  accurate  determinations  in  the  availah 
AFIT/CIV  must  make  some  operational  decisions  to  standardize  t 


.elation 


es  for 


-UESTED, 


student 
iced  by 
CODE  is 
e  as  in 


.FIT/CIV 

>) 


s  which 


are  in 
•  marked 
attri- 


;  actri- 
onncl  to 
>ich  too 
.ed  con- 
e  t ime . 
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